一些观点，Rust vs. Go

[laputa]

这几天，在微博上看到一些观点。

@laiyonghao：说 go 好的人，都没有看过 rust。

@GeniusVczh：我看了rust之后也觉得go完全无法与之相比。

@GeniusVczh：以前为了做compiler，研读+实现了几乎所有种类的语言。现在看语法手册几乎很快就可以理解整个语言的内容。后来我对比了一下go和rust，发现go的类型系统简直就是拼凑的。这会导致跟C语言一样，需要高超的技巧才能写大程序。而rust则没有这种问题，每个部分的组成都很和谐。

@GeniusVczh：你应该先去研究一下那两个语言。tips（只实现了function就自动apply interface的这个设计是很糟糕的，但是一般OO语言那种继承方式也不是必要的，我们有concept mapping）

不知道大家有何看法？

粗略看了一下rust，确实很强大，也有一些很赞的特性。不过不来电，不是我的菜，我还是比较喜欢Gopher这个贴心的萌货。哈哈~

鉴于个人能力有限，不像vczh这种搞compiler的大拿，...

所以，抛砖等玉

有木有达人出来说道说道~

[Marvin Guo]

Rust是挺优秀的，函数式本来就比命令式来的优雅。但同时也要看到，两种语言的定位不同。Go的定位是

取代C(或C++),做所有软件的基础。而Rust想是一种划时代的语言，如果成功，将是颠覆性的。

但同时也应该看到,

Go的目标简单，现在也比较稳定，可以使用了

而Rust虽然很强大，但它还处于很早期的阶段，一切还有待于发展。

如果Rust能实现其大部分特性，将是十分优秀的语言，期待。

Marvin

http://cnblogs.com/chrome

2012/3/9 laputa <ye.l...@gmail.com>

--
来自: Golang-China ~ 中文Go语言技术邮件列表
详情: http://groups.google.com/group/golang-china
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina

[sj l]

从语法的顺眼度看，rust完胜go，菜鸟路过

2012/3/9 laputa <ye.l...@gmail.com>

--

[fango]

Hoare说：“程序员一直被复杂性包围；我们无从逃避。我们应用的复杂出于我们的野心，总是想把我们的计算机用得更精密。我们程序的复杂是因为每个编程项目都有大量矛盾的目的。如果我们基本的工具——我们自己设计的、编制我们自己代码的语言——也被复杂化，那语言自身就成了问题、而不是解决方案的一部分。”

这个Hoare，不是rust的Hoare，是Go的CSP的祖师爷quicksort的发明人Hoare。他的这句话是发表在《皇帝的旧衣》一文。大家可以看看，rust是不是旧衣的堆叠？

fango

[laputa]

我也有类似的疑问，是集大成，还是大杂烩？

Additional specific influences can be seen from the following languages:

• The stack-growth implementation of Go.
• The structural algebraic types and compilation manager of SML.
• The attribute and assembly systems of C#.
• The deterministic destructor system of C++.
• The typeclass system of Haskell.
• The lexical identifier rule of Python.
• The block syntax of Ruby.

2012/3/9 fango <fan.h...@gmail.com>

[sj l]

好东西总是吸收前人的经验吧，怎么可能重新发明一切轮子

2012/3/9 laputa <ye.l...@gmail.com>

[Oling Cat]

一直很喜欢函数式编程，这个单看语法就感觉很舒服啊...

研究一下....

--

Hello! This is Oling Cat!

2012/3/9 laputa <ye.l...@gmail.com>

[laputa]

我不是那个意思，是“一致性”的问题，两个好东西放在一起未必更好。

这个经验有限，不好发表什么阔论~

2012/3/9 sj l <shuxi...@gmail.com>

好东西总是吸收前人的经验吧，怎么可能重新发明一切轮子

[lihui]

木有感觉这个语法顺眼，还是挺凌乱的感觉。 从语法形式上讲，还是喜欢scala。期望scala on llvm早点出来。

2012/3/9 Oling Cat <olin...@gmail.com>

[lihui]

最近关注dart比go多了，越来越觉得go这帮人不懂得应用开发。

2012/3/9 lihui <ustc....@gmail.com>

[windstorm]

语言之争很费时间的，没必要和这帮人说。每个人都有自己的偏好，有的人就对Java来电，有的人就不喜欢Go，你说啥都没用的。自己用着舒服就醒了。

顺便提醒你一下，意见有没有道理不是说某个compiler大拿就能判定的。首先是不是大拿，多大拿另说，如果你问rob
pike，他肯定说Go比Rust好，rob和这个人比谁更大拿？Linus说C++ sucks，难不成C++程序员全换行业了？

自己专心做自己的事情就是了。

至于那句“作者竟然说学完C++的时间和用go写64个开源项目的时间一样多”，呵呵，他明显没看懂这个玩笑。

----------------------------------------------------------------------------------
Yours Sincerely
Kun

gplus.to/kunli

2012/3/8 lihui <ustc....@gmail.com>:

[windstorm]

是么？Go team的人里面，应用开发的大拿其实还是不少的

Go推出的主要目的之一就是G内部大东西太多了，系统级开发巨型项目非常痛苦，所以估计Go开发时和不同team都有沟通交流，要address的问题很多就是巨型开发team中的实际问题。举个例子，Go的interface就是专为大型应用项目设计的，原因大家也都知道吧。Go的优点在实际大型应用项目已经体现，而且不是说除了Google没人用，用了的人反馈是什么样的，大家估计也有所耳闻

总的来说，可能语言还新，还需要改善吧。但要说"不懂得"，这个有点过了。

Dart team起点就不一样，因为javascript实在太......那个了。但Dart始终还是主营前端吧。这俩基本就没法比较。

----------------------------------------------------------------------------------
Yours Sincerely
Kun

gplus.to/kunli

2012/3/8 lihui <ustc....@gmail.com>:
>

[laputa]

擦，赞同一个。

不过话说回来，虽然我们认准Ken Thompson、Rob Pike、Linus这样的“标识”，

但是从普通人角度讲，我们不能跟他们比肩呐...

就像，别人用emacs，我只会vim - -

另外，毕竟是新语言，争一争没什么的

如果可能的话，我还是会希望去说服身边的一些人去使用Go ：）

2012/3/9 windstorm <likunar...@gmail.com>

[windstorm]

我用Go并不是因为Ken Thompson、Rob Pike这帮人，我觉得C++ sucks也不是因为Linus。那就是我用过之后喜欢还是不喜欢而已。

不要迷信权威。说服别人用Go最好的办法不是拉出一帮名人说观点，而是做一个牛逼的项目和库出来，让别人主动想用

----------------------------------------------------------------------------------
Yours Sincerely
Kun

gplus.to/kunli

2012/3/8 laputa <ye.l...@gmail.com>:

[laputa]

语言终究是工具，陷于嘴皮之争，确实是非常无聊的事情。

至于名人观点么，Paul说Lisp是最好的语言没有之一，我也不会真的去用。

但是，多了解，兼听则明，我个人觉得没什么坏处。

2012/3/9 windstorm <likunar...@gmail.com>

[zhai]

Rust于2006开始动工，2012年1月出0.1 alpha 版,目前没有预定的时间推出beta版，照这个进度，出到1.0恐怕还遥遥无期。

2012/3/9 laputa <ye.l...@gmail.com>

[Dang Allen]

非常赞同windstorm兄的观点！

[laputa]

起步这么早，我还以为是有一帮子人看Go不顺眼，然后整的呢

很多地方有Go的影子~

2012/3/9 zhai <qyz...@gmail.com>

[Xing Xing]

围脖上我看到这条了，总的来说，老赖那句话可以认为是 yet another joke.
至于 vczh
到底是在故意挖坑，还是认真在对比两个语言，我不熟悉他，不好评价。如果要认真来说，对于我这么愚钝的人来说，
rust 显然过于复杂了，go 也好不到哪里去，但总要好一些。

另外，如果真心要比较语言和语言之间的差异，先从起源或者说设计目的讲起；
从语言设计出来后，首先要解决的问题来分析会比较容易避免口水战。

至少，在这点上 go 的目标很明确（还记得 go 官方对于 gui
开发的态度吧？）。rust 让人感觉并不清晰。没有银弹，但 rust
似乎想当银弹呢？

于 Thu,

[minux]

2012/3/9 Xing Xing <mike...@gmail.com>

至少，在这点上 go 的目标很明确（还记得 go 官方对于 gui 

开发的态度吧？）。

我想知道你觉得官方对于gui是啥态度？

[Liigo Zhuang]

我前一阵也简单看过一点 Rust 的语法，有几点感觉很不爽：

1、std::io::print() // 这里 :: 的用法太繁了吧，为什么不用点(.)

2、fn main() -> int  // 函数的返回类型前面用 -> 感觉是多余的

3、use 和 import 并存，有必要吗？

[Liigo Zhuang]

现在对 GO 语言，我关注挺长时间，感觉作者们控制的很严格，很多很好的建议都被拒绝了，参见 golang-nuts 邮件组。有些建议，他们只需要做很少的工作，就能有很好的效果，他们就是拒绝改进。

[qq wu]

这个，GUI库明显不在Go Team的开发日程之内。我觉得用swig做一个其它GUI库（比如Qt）的绑定，像pyQt那样才是比较好的模式。

至于rust，会不会走D语言的老路啊？

2012/3/9 minux <minu...@gmail.com>

[Jay True]

不是不做，而是语言设计上的考虑吧。举个例子？

On Fri, Mar 9, 2012 at 4:32 PM, Liigo Zhuang <com....@gmail.com> wrote:

现在对 GO 语言，我关注挺长时间，感觉作者们控制的很严格，很多很好的建议都被拒绝了，参见 golang-nuts 邮件组。有些建议，他们只需要做很少的工作，就能有很好的效果，他们就是拒绝改进。

--

[minux]

2012/3/9 Liigo Zhuang <com....@gmail.com>

现在对 GO 语言，我关注挺长时间，感觉作者们控制的很严格，很多很好的建议都被拒绝了，参见 golang-nuts 邮件组。有些建议，他们只需要做很少的工作，就能有很好的效果，他们就是拒绝改进。

比如什么？我猜想你是说'#!'么？

我觉得控制得严格些有好处。因为加入一个特性简单，但是你要想从语言中去掉一个已有的特性就难了。

如果一个特性可以被外部有效地实现(比如用gorun实现#!)，那么就没有必要增加语言本身的复杂性。

所以不是Go team懒惰，连一些很简单实现的建议都不采纳(#!)或者说拒绝改进。

我认为Go还是要简单、一致(正交性)上取胜的。这符合Unix界软件的一贯风格，换句话说就是KISS原则。

[Liigo Zhuang]

2012/3/9 Jay True <gla...@gmail.com>

不是不做，而是语言设计上的考虑吧。举个例子？

1. "Proposed new pkg/testing function" 建议为 pkg/testing 增加 AssertEqual()

https://groups.google.com/d/topic/golang-nuts/6hmxZY8IQNQ/discussion

2. "Last Gasp Call for Native Decimal Support" 建议增加与浮点数相对应的固定精度小数

https://groups.google.com/d/topic/golang-nuts/YczDW-4QMtE/discussion

3. "Using go run with #!" 建议gc编译器忽略.go文件中以#!开文的第一行

https://groups.google.com/d/topic/golang-nuts/3U94EmLQdqI/discussion

都是讨论很热烈的帖子。GO开发者的原则性太强了，根本听不进去好建议。

[minux]

2012/3/9 qq wu <wuq...@gmail.com>

这个，GUI库明显不在Go Team的开发日程之内。我觉得用swig做一个其它GUI库（比如Qt）的绑定，像pyQt那样才是比较好的模式。

其实在golang-nuts上最近的关于GUI的口水战已经有多个Go team的人出来解释了。最主要的问题是，

现在根本没有一个公认的跨平台GUI库。而且他们不是做GUI出身的人，如果贸然自己写一个，估计只会

被别人笑话。(这点不是真的，其实Rob Pike早前还真是做过GUI相关的工作，只不过那些东西都是给程序员用的，

一般计算机用户肯定不会接受，看看Acme和Rio就知道了)

就像database/sql包一样，不也是进化了很长时间才加入标准库的么。

swig本来就支持Go，所以做任何一个GUI库的go binding都不是难事儿。难的是，你如何融合Go的特性和

GUI库的接口？

Go team的roadmap里面没有GUI，并不代表他们不准备接收外部贡献。如果真有一个外部项目被广泛接受，

且能在所有支持的平台上运行，他们肯定会考虑merge的。

PS：其实Go里面原来有一个exp/wingui的包的，后来被移出去了code.google.com/p/gowingui。而且外部也有

X Window system的Go binding，我印象里也是从标准库中移出去的，但是这两个都是Go Team维护的，且也

是要通过golang-dev review任何改动的。

[minux]

2012/3/9 Liigo Zhuang <com....@gmail.com>

1. "Proposed new pkg/testing function" 建议为 pkg/testing 增加 AssertEqual()

https://groups.google.com/d/topic/golang-nuts/6hmxZY8IQNQ/discussion

这个外部做也没问题。 这个不接受主要还是觉得这样做增加了不必要的复杂性。

2. "Last Gasp Call for Native Decimal Support" 建议增加与浮点数相对应的固定精度小数

https://groups.google.com/d/topic/golang-nuts/YczDW-4QMtE/discussion

这个真没说不加，只是说提得太晚了，Go 1赶不及了，而且提的时候已经Go 1 API freeze了。

3. "Using go run with #!" 建议gc编译器忽略.go文件中以#!开文的第一行

https://groups.google.com/d/topic/golang-nuts/3U94EmLQdqI/discussion

我已经解释过了。外部的处理方式更好，而且能缓存编译出来的程序。

PS: 对于bash来说，这个讨论中给出了一个很优雅的方案：

//usr/bin/env go run "$0" "$@"; exit $?

package main

func main() { println("hello world."); }

总结一下，看来大家都喜欢大而全的东西。但是我觉得Go的美恰恰是小而精。

[fango]

> 总结一下，看来大家都喜欢大而全的东西。但是我觉得Go的美恰恰是小而精。

对。Less is more。有失才有得。

fango

[Liigo Zhuang]

好吧，咱们就来谈谈你提出的 “简单、一致（正交性）” 和 KISS 原则：

http://tip.golang.org/doc/go_faq.html#nil_error

http://tip.golang.org/doc/go_faq.html#unused_variables_and_imports

http://tip.golang.org/doc/go_faq.html#methods_on_values_or_pointers

当你一次次用大篇幅文字向初学者解释那些原本应该很简单的问题时，你还谈什么“简单、一致、KISS原则”？

与其一遍遍的解释，还不如自己（GO语言设计者开发者）多做一点工作，对GO语言和编译器做一些改动，把问题消弭于无形。

以 “为什么 { 不能单独一行？” 为例，为什么呢，因为编译器会在上一行末尾自动添加一个分号，为什么自动加分号呢，因为编译器作者想省事！明明程序员没有写分号，你非要加分号，要说是编译器的内部处理细节也无所谓了，你还要把它公之于众，甚至反过来影响到程序员写代码的方式。这在编程史上恐怕真是绝无仅有！

其实，我更希望编程语言的开发者多做一些工作，让程序员们少做一些功课。因为，前者的工作虽然复杂，但只需做一次，就造福数百万程序员；而后者每人每天多写一行代码、多留一分迷惑，累加起来也是很大的浪费。

2012/3/9 minux <minu...@gmail.com>

[Sparkle]

这个还是得第三方来做
比如说wxpython就不是python的官方库
不过现在go的第三方库的确不怎么给力

2012/3/9 minux <minu...@gmail.com>:

> --
> 来自: Golang-China ~ 中文Go语言技术邮件列表
> 详情: http://groups.google.com/group/golang-china
> 官网: http://golang-china.org/
> IRC: irc.freenode.net #golang-china
> @golangchina

--
blog: http://weavesky.com
twitter: sparklezeng
weibo: sparklezeng

[lihui]

都说正交正交，但看到Go的很多语言特性，只有内置的才有，用户定义的就没有，就很难接受正交性的说法，更加谈不上一致性。

或许正交性和一致性说的不是我所理解的意思，而是指内置类型总是与用户定义类型不同。

2012/3/9 minux <minu...@gmail.com>

[laputa]

对于这个问题，我的理解是，一些强制性的规则，可以让人免于“布理当驴”的选择困境。

简单粗暴，但有效~ ：）

2012/3/9 Liigo Zhuang <com....@gmail.com>

[Jay True]

On Fri, Mar 9, 2012 at 5:47 PM, Liigo Zhuang <com....@gmail.com> wrote:

好吧，咱们就来谈谈你提出的 “简单、一致（正交性）” 和 KISS 原则：

http://tip.golang.org/doc/go_faq.html#nil_error

http://tip.golang.org/doc/go_faq.html#unused_variables_and_imports

http://tip.golang.org/doc/go_faq.html#methods_on_values_or_pointers

当你一次次用大篇幅文字向初学者解释那些原本应该很简单的问题时，你还谈什么“简单、一致、KISS原则”？

与其一遍遍的解释，还不如自己（GO语言设计者开发者）多做一点工作，对GO语言和编译器做一些改动，把问题消弭于无形。

以 “为什么 { 不能单独一行？” 为例，为什么呢，因为编译器会在上一行末尾自动添加一个分号，为什么自动加分号呢，因为编译器作者想省事！明明程序员没有写分号，你非要加分号，要说是编译器的内部处理细节也无所谓了，你还要把它公之于众，甚至反过来影响到程序员写代码的方式。这在编程史上恐怕真是绝无仅有！

看到这个，我第一个想到的是，Python 强制通过缩进来标识代码块的范围。我只是觉得这是品味问题，就好像一开始的 C 语言选择大括号作为代码块标识，而不是其他什么符号一样吧。

[minux]

我承认目前Golang的设计中正交性还是不够的，最主要的就集中在generic上，这是

导致有些内置函数比如append你不能写类似物的主要原因，这个在roadmap上，但是

目前确实没有讨论出好的解决方法。如果你有，请不吝赐教。

2012/3/9 Liigo Zhuang <com....@gmail.com>

好吧，咱们就来谈谈你提出的 “简单、一致（正交性）” 和 KISS 原则：

http://tip.golang.org/doc/go_faq.html#nil_error

http://tip.golang.org/doc/go_faq.html#unused_variables_and_imports

这个没问题。从长久考虑，这是好事儿，时刻让你的代码不留下无用代码。不但提高编译速度，也提高代码质量。

http://tip.golang.org/doc/go_faq.html#methods_on_values_or_pointers

当你一次次用大篇幅文字向初学者解释那些原本应该很简单的问题时，你还谈什么“简单、一致、KISS原则”？

参见本文的最后，Simple的含义不是学习起来简单。 

与其一遍遍的解释，还不如自己（GO语言设计者开发者）多做一点工作，对GO语言和编译器做一些改动，把问题消弭于无形。

这几个问题你是否有更好的解决方案？如果有，那赶紧提出来。

请不要空谈“多做一点工作，让问题消失”，请具体地指出来到底需要怎么做？

以 “为什么 { 不能单独一行？” 为例，为什么呢，因为编译器会在上一行末尾自动添加一个分号，为什么自动加分号呢，因为编译器作者想省事！明明程序员没有写分号，你非要加分号，要说是编译器的内部处理细节也无所谓了，你还要把它公之于众，甚至反过来影响到程序员写代码的方式。这在编程史上恐怕真是绝无仅有！

你用过Javascript么？

为了尽可能不让程序员添加分号，你是否有更好的做法？(请不要光说，你来实现一个怎么样？你准备如何保证

你实现的正确性？)

另外，去看看Haskell的处理方式。编译器自动添加一些语法成分这件事情真没有你想象地那么罕见。

关于这种程序格式不那么自由的问题，也不是Go特有的，Python不也是如此。

其实，我更希望编程语言的开发者多做一些工作，让程序员们少做一些功课。因为，前者的工作虽然复杂，但只需做一次，就造福数百万程序员；而后者每人每天多写一行代码、多留一分迷惑，累加起来也是很大的浪费。

把 { 单独一行是多写一行代码好吧？想办法不要程序员写分号不是让程序员少作一些事情么？

(你可以认为你学习了一次，以后工作中永远不用写分号，跟学习Unix是一样的，学习的成本高，但是肯定后来是省事儿的)

认为学习成本高的程序员，我觉得还是不要尝试Go了。用你已经会的东西吧，不需要学习任何新的东西，多好？

建议你看看Worse is better的讨论，没办法Unix风格确实是把实现的优雅性排在比较靠前的位置的，但是实际上

这是成功的，不然也不会有人提这个说法了。

复杂的实现基本上等价于更多的bug，这个也是公认的结论了。

[minux]

2012/3/9 Sparkle <pop...@gmail.com>

这个还是得第三方来做

恩  Go team说了他们不是专家。GUI这东西真不是随便谁都能设计得好的。 

比如说wxpython就不是python的官方库

Python主要是内置了Tk。这点不错，虽然我不知道有多少人用Python开发GUI程序的时候会选择它。 

不过现在go的第三方库的确不怎么给力

呵呵 Go还太年轻，才刚刚要到1.0，ecosystem会慢慢建立的。 

[minux]

2012/3/9 laputa <ye.l...@gmail.com>

对于这个问题，我的理解是，一些强制性的规则，可以让人免于“布理当驴”的选择困境。

简单粗暴，但有效~ ：）

比如gofmt就解决了程序格式风格的永恒的争论。有些时候这还是很有意义的。

不然总是争论那个写法才是最好的这类问题，Go team没办法做别的事儿了。

[minux]

2012/3/9 Jay True <gla...@gmail.com>

On Fri, Mar 9, 2012 at 5:47 PM, Liigo Zhuang <com....@gmail.com> wrote:

好吧，咱们就来谈谈你提出的 “简单、一致（正交性）” 和 KISS 原则：

http://tip.golang.org/doc/go_faq.html#nil_error

http://tip.golang.org/doc/go_faq.html#unused_variables_and_imports

http://tip.golang.org/doc/go_faq.html#methods_on_values_or_pointers

当你一次次用大篇幅文字向初学者解释那些原本应该很简单的问题时，你还谈什么“简单、一致、KISS原则”？

与其一遍遍的解释，还不如自己（GO语言设计者开发者）多做一点工作，对GO语言和编译器做一些改动，把问题消弭于无形。

以 “为什么 { 不能单独一行？” 为例，为什么呢，因为编译器会在上一行末尾自动添加一个分号，为什么自动加分号呢，因为编译器作者想省事！明明程序员没有写分号，你非要加分号，要说是编译器的内部处理细节也无所谓了，你还要把它公之于众，甚至反过来影响到程序员写代码的方式。这在编程史上恐怕真是绝无仅有！

看到这个，我第一个想到的是，Python 强制通过缩进来标识代码块的范围。我只是觉得这是品味问题，就好像一开始的 C 语言选择大括号作为代码块标识，而不是其他什么符号一样吧。

对，强制{不能换行这真不是啥大不了的问题。像Python那样不也是很成功么。

[Xing Xing]

于 Fri, 9 Mar 2012 18:16:00 +0800
minux <minu...@gmail.com> 写道:

> 2012/3/9 Sparkle <pop...@gmail.com>
>
> > 这个还是得第三方来做
> >
> 恩 Go team说了他们不是专家。GUI这东西真不是随便谁都能设计得好的。

喏，我都说有人会记得 Go 官方的态度了……
Go 现在的任务，不是变成超级武器，先做好 Server side。
对于 GUI 这些更加上层的建筑，以后再说吧。

至于第三方库的问题，或者 wingui 的问题，其实就是一个聚焦点的问题。
我提交过一两个 patch 都被否了，在沟通过程中就发现，对于增加功能，
Go team 非常谨慎。

[minux]

2012/3/9 Xing Xing <mike...@gmail.com>

Go 现在的任务，不是变成超级武器，先做好 Server side。
对于 GUI 这些更加上层的建筑，以后再说吧。

GUI这事儿，还是交给Chrome(OS)去做吧。Web应用会是主流的。

 

至于第三方库的问题，或者 wingui 的问题，其实就是一个聚焦点的问题。
我提交过一两个 patch 都被否了，在沟通过程中就发现，对于增加功能，
Go team 非常谨慎。

en 我也被否过好几个。但是能理解他们的态度。特性这玩意加容易，去掉难。

所以还是得仔细想明白了再加为好。没有某个特性固然让人郁闷，但是有很多

无用或者设计欠考虑的特性我觉得会更让人郁闷。

不过对于你的database/sql.Open的改动(CL 5706047)，如果再早点提估计会好些。

[lihui]

不仅仅是generic的问题。 generic 在Go上基本是无解的，因为Go在设计之初就是考虑不提供泛型的，这就是为什么map（ 还是个性能杀手） 等东西存在的原因。

其他不一致的地方有：

缺乏操作符重载

内置类型一概没有方法

v,ok:=map[x]中对ok的特殊处理

缺乏一般性的可调用对象的概念

对foreach的支持不对用户定义类型开放等等

值变量可以调用指针方法，而interface里的值就不行

make与new的存在

以前还有符号的Export和可赋值性强行绑定在一起，WTF！，不过好在现在似乎改过来了。

可以说，Go里面到处充满着特殊处理，不是语言特性之间具有强相关性，就是补丁式的，所以不能理解这个正交性和一致性的说法是怎么来的。

2012/3/9 minux <minu...@gmail.com>

--

[laputa]

支持这种奥卡姆剃刀的精神。

2012/3/9 minux <minu...@gmail.com>

--

[lihui]

跨平台的GUI设计是一个很困难的工作，这个就不用抱有什么希望了。个人觉得设计好了这个东西，几乎就完成了操作系统一半的工作量了。

2012/3/9 minux <minu...@gmail.com>

--

[laputa]

了解一个语言的弱点，和了解它的优势一样重要。

这个比vczh的具体多了~

2012/3/9 lihui <ustc....@gmail.com>

[qq wu]

就是啊，如果你要进行本地GUI开发的话， 为什么要选择GO这种目前还是小众的语言呢？桌面GUI技术也发展了这么多年了。

2012/3/9 minux <minu...@gmail.com>

[laputa]

 我觉得进入GUI是迟早的事情，不过相对长远。它首先会考虑支持Android吧~

2012/3/9 qq wu <wuq...@gmail.com>

--

[qq wu]

再过两年，HTML5应用更普及，手机性能更好，连 Android 也会 Web 化了。

2012/3/9 laputa <ye.l...@gmail.com>

[Liigo Zhuang]

这都是GO独有的问题，几乎其它所有编程语言都不存在这类问题。也就是说，大多数编程语言的开发者都想到了解决方案并且解决了。或者说，解决方案多到数不清，一个普通程序员都有很简单的解决方案：

以 “{” 为例，取消“自动添加分号”不就行了吗？你自己为“省事”（想投机取巧）而引入的麻烦，还得要自己解决（局部重写编译器吧，这个不怪别人，你前面的工作就没做好）。变量与接口的转换那个问题，在别的语言里怎么没有？还是你自己引入的易混淆的概念。怎么解决？令 var err = nil; return err; 等效于 return nil。这两者之间再细分的话（他们坚持细分），感觉走火入魔了。

2012/3/9 minux <minu...@gmail.com>

--

[Uhioins Dell]

go的设计初衷就“简单”，对于那些强大的功能设计一个强大的库，既保持了语法的简洁。又能高效运作不是更好么，相信大部人学习它，就是因为其简洁的语法。

[Liigo Zhuang]

我同意 " Worse is better " 。可是，以分号的使用为例：C语言要求所有语句以分号结尾，很明确；Python不需要以分号结尾，也很明确；偏偏GO整出来一个“程序员多数情况下不需要分号结尾，但某些情况下编译器会帮忙加上分号”，而且还把“什么情况自动加分号”大摇大摆地写入语言规范。在这个世界上，不需要以分号结尾的语言多了去了，象GO这样做事情做一半的少之又少，就不能彻底把分号去掉吗？没那么难吧？

2012/3/9 minux <minu...@gmail.com>

--

[minux]

2012/3/9 lihui <ustc....@gmail.com>

不仅仅是generic的问题。 generic 在Go上基本是无解的，因为Go在设计之初就是考虑不提供泛型的，这就是为什么map（ 还是个性能杀手） 等东西存在的原因。

不是，他们没找到好的解决办法。 原来roadmap文档上还包括这里呢。这个和对待异常

处理态度真不一样。异常处理那是绝对不会有，这个是还在讨论。

现在最关键的就是性能方面的考虑，参看Russ Cox的这个总结：

The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times?

当然，第二点不应该是and的关系，好的编译器可以不造成binary bloat，但是slow compiler的问题是没办法解决的。

其他不一致的地方有：

hehe  不错 总结了这么多不一致的地方～ 

缺乏操作符重载

哪些操作符允许重载呢？还有这样是否真的有好处？会不会搞得像C++那样超级复杂？

内置类型一概没有方法

这个没啥问题，你只要定义一个alias就能设置方法了。

用Ruby的人估计会有这个体会，如果大家都随意给内置类型加方法，很快就会乱套。

所以内置类型不能添加方法。

至于内置类型为啥没有内置方法的问题，我觉得如果不能定制有哪些方法，那么固定

的一套就容易不够。而且更重要的一点是如果有了内置的方法，这就是语言spec的一

部分了，这东西作为标准库里的函数是可以改的(主要添加)，如果把他们放到语言spec

里去就非常非常不容易改了。(改doc/go_spec.html似乎至少得得到几个核心人物的LGTM

才能通过，标准库的改动就轻松得多)

v,ok:=map[x]中对ok的特殊处理

你是否有更好的处理？改成内置函数？其实我觉得v, ok这样的设计挺符合Go关于错误

处理的一致性的。而且这种处理的好处也很明显，如果你v := map[x]那么也明确表明

你不在乎x是否存在，就像 v, _ := somefunc()这样，明确告知你不愿意处理错误了。

如果设计成一个函数，虽然也可以，但是map类型内置就真没必要了。 

缺乏一般性的可调用对象的概念

你举个例子说这个吧。

对foreach的支持不对用户定义类型开放等等

这是个问题，而且我觉得会要解决的，类似Lua的方式就很好，况且Go是有closure的，

那个方式+Go独有的Interface机制会有比较好的设计的，至少我这么认为，我没看过

关于这个问题的讨论，不知道Go Team是什么态度。 

值变量可以调用指针方法，而interface里的值就不行

我还没仔细想过这个问题的原因。暂时不能评论这个问题。

make与new的存在

是有点郁闷，有了literal的写法之后确实是可以去掉new的。 

以前还有符号的Export和可赋值性强行绑定在一起，WTF！，不过好在现在似乎改过来了。

可以说，Go里面到处充满着特殊处理，不是语言特性之间具有强相关性，就是补丁式的，所以不能理解这个正交性和一致性的说法是怎么来的。

正交性和一致性是语言的设计目标。但是不是唯一或者说最重要的目标。

如果只考虑正交性的话，那语言我估计也就是Ruby比较接近了。性能受的影响太大了，真的。

而且毕竟Go是想作新时代的C语言，有些东西必须得坚持。比如可以让程序员完完整整地控制struct

在内存从的layout等等。所以有些东西还是不能考虑动态的(如果要正交地像Ruby那样的话)

PS: 上面提到了C++, Ruby, Lua等若干种语言，但是我没有任何批评他们的意思。更多的时候是

借鉴他们的设计，毕竟每个语言中都必须要有特定的tradeoff关系。我觉得只有把握了那个语言

设计者考虑的“主要矛盾”才能理解那个语言的某些你觉得诡异的特性。当然，我肯定不是认为Go

现在就是完美的。其实我上面也说了，有几个地方是我也觉得该改进的。

[laputa]

如果{是否可以单独一行只是个个人口味问题，我觉得可以不用深究。如果编程语言只是个个人使用产品，个性化是更好的选择，但作为团队开发，强制一些规则，能够统一还是统一为好。

有几点不懂，请教一下：）

1. 你自己为“省事”（想投机取巧）而引入的麻烦，还得要自己解决（局部重写编译器吧，这个不怪别人，你前面的工作就没做好）。

2. 变量与接口的转换那个问题，在别的语言里怎么没有？还是你自己引入的易混淆的概念。怎么解决？令 var err = nil; return err; 等效于 return nil。

这两个是怎么回事，有木有详细点的资料？

2012/3/9 Liigo Zhuang <com....@gmail.com>

[Liigo Zhuang]

我前面对GO语言吐槽挺多的，呵呵。

我（liigo）在此声明一点：我对Go语言没有敌意，不是为黑Go语言而来的，也不是想故意挑起Go语言和Rust语言之间的战争（况且我先讲了Rust的几点不爽）。

我前面对GO语言吐槽，仅限于吐槽，发泄一些不满而已。能促进它改进更好，不能也罢。我始终认为，一味的维护它的不足，一味的自我满足，不利于它的成长。如果我讲话的方式和语气给大家造成不爽，我表示道歉。

对于Go语言的了解，和对它的关注，我还是花了很多精力的：至少2012春节前后的这几个月，我跟踪了Go源代码库里的每一条代码提交记录。我之所以花精力关注它，是希望它发展的更好，能成为我更顺手的工具。

[minux]

2012/3/9 Liigo Zhuang <com....@gmail.com>

这都是GO独有的问题，几乎其它所有编程语言都不存在这类问题。也就是说，大多数编程语言的开发者都想到了解决方案并且解决了。或者说，解决方案多到数不清，一个普通程序员都有很简单的解决方案：

以 “{” 为例，取消“自动添加分号”不就行了吗？你自己为“省事”（想投机取巧）而引入的麻烦，还得要自己解决（局部重写编译器吧，这个不怪别人，你前面的工作

为啥要为了这么简单的事情放弃没有分号的特性？ 

为啥要有分号？请问你如何解决在语句本身可以换行(总有一行放不下或者想对齐些东西的时候)的情况下区分开两条

相邻语句？？

我觉得这么争论没意义，如果你认为自己能解决这个问题，请试试。说是一件事，做是另一件事情。

比如说，觉得Go哪里不好，你可以fork它，然后改嘛。BSD协议那么宽松。为啥要这里批评Go Team呢？

(我其实很有冲动说FreeBSD社区的一句名言，哈哈哈)

你fork一个，没准用的人比Original Go还多呢，到时候Google就该解散了Go Team了让你来做了，多好的事情。

就没做好）。变量与接口的转换那个问题，在别的语言里怎么没有？还是你自己引入的易混淆的概念。怎么解决？令 var err = nil; return err; 等效于 return nil。这两者之间再细分的话（他们坚持细分），感觉走火入魔了。

哪个语言要引入与众不同的概念，都有可能遇到这样的问题。知道了实现就明白了，这不是啥问题。

如果你非要说自己故意引入易混淆的概念，那么就去看看Lisp社区，为了确定‘()和nil以及false到底是不是

一个东西，打了那么多年，出了那么多dialect，然后发现这样做除了伤自己的元气之外，没有好处。最后

还是倾向于统一到Common Lisp上来(以及Scheme)。呵呵，说得多了。

确实可以让var err someError = nil; return err; 等效于return nil，但是这是给特例打补丁，增加了实现的复杂性，

还是那句话，要理解Go请先理解Unix和Plan 9，他们的KISS原则里面的Simple不是一般意义的理解。

我继续推荐Worse is better在wikipedia上的解释以及相关的讨论。

[laputa]

囧，其实我想多听听“反面”观点呢，毕竟这世上不存在所谓完美的事物~

窃以为，了解这些的过程中，可以学到的东西很多

2012/3/9 Liigo Zhuang <com....@gmail.com>

--

[minux]

2012/3/9 Liigo Zhuang <com....@gmail.com>

我同意 " Worse is better " 。可是，以分号的使用为例：C语言要求所有语句以分号结尾，很明确；Python不需要以分号结尾，也很明确；偏偏GO整出来一个“程序员多数情况下不需要分号结尾，但某些情况下编译器会帮忙加上分号”，而且还把“什么情况自动加分号”大摇大摆地写入语言规范。在这个世界上，不需要以分号结尾的语言多了去了，象GO这样做事情做一半的少之又少，就不能彻底把分号去掉吗？没那么难吧？

因为我既可以使用传统Go风格不写分号，我也可以用分号，把不同语句放到一行。

这是个权衡。你是不可能完全去掉语句的结束符的(也就是;号在C/Go里面的作用)，如果没有，那是因为回车就是。

但是这所谓的隐式结束符就导致你无论如何不能把多个语句放到同一行了。

肯定是各有利弊。

再说一点，把自动添加分号写入语言规范怎么了？Javascript也是。

[minux]

2012/3/9 laputa <ye.l...@gmail.com>

囧，其实我想多听听“反面”观点呢，毕竟这世上不存在所谓完美的事物~

窃以为，了解这些的过程中，可以学到的东西很多

对的。没有一种语言适合做所有事情。了解他所使用的所有语言的优缺点和适用范围是

最重要的一件事情。

题外话：

其实我认为最佳的程序员面试题是这样的：

1，请说出你最喜欢的计算机语言。

2，请说出你最喜欢的计算机语言中你觉得最烂的设计是哪里，你有没有改进的方式？

3，你有没有实现过你设想的改进？如果实现过，是否给别人用过你改进的语言？

[Liigo Zhuang]

“make与new的存在”，我也想再吐吐槽。现在Go语言里创建对象的办法，大概有四种：new, make, struct literal, special func。假设某个pkg公开了一个struct A，怎么创建A类型的变量？我要先去文档里查查有没有 NewA() 之类的函数，如果有，一般来说你就不能用new(A)或A{...}这类方法初始化。这里又牵涉出Go对象没有构造函数的问题，正是因为没有构造函数，所以不能轻易使用new(A)或A{...}。如果核实了库作者没有提供NewA()函数，你就只能用new或A{...}；等将来那个库升级又添加了NewA()，你旧代码还可能创建出未正确初始化的变量（编译器还没能力编译警告）。真是纠结。反而没有直接调用构造函数省心。

2012/3/9 lihui <ustc....@gmail.com>

[lihui]

缺乏一般性的可调用对象的概念——你举个例子说这个吧。

  就是一个对象，可以作为函数来调用。这主要体现在需要回调函数的时候，由于Go中对象不能是可调用函数，因为单方法接口总是比回调函数更加一般（generic）些。所以Go倾向于使用只有一个方法的接口来解决这个问题，并且使用神奇的手法，将与接口方法签名等价的函数转型为满足该接口值。

而在支持可调用函数的语言，如scala、dart中，则不存在这个问题，因此大量的使用函数参数而不是但方法接口。

但使用单方法接口是痛苦的，其一：闭包函数需要经过一层转换。其二：你不能在函数内部现场定义一个匿名的实现了该接口的类。

以前大家都说闭包函数是穷人的对象，但从本质上来说，应该是穷人的可调用对象。 

make和new的存在其根源在于缺乏构造函数而产生的。

ok这种东西，我承认它是有效的，实际上Go的很多设计，都是有效的。不过，一个真正正交的语言，必然是魔幻语言，表示空间绝对地由各特征维度划定，没有被拍扁嘛，scala就是一个经典的例子。

ps：关于那个ok，我一直希望err的返回值也能一样处理（从而更加一致了），即如果存在错误，但用户没有赋值给一个变量检查，就panic，而不是像现在一样，默默无声地运行下去，然后不知道在那一行就挂掉。 go现在鼓励的错误处理方式，比checkedException还要邪恶。

2012/3/9 minux <minu...@gmail.com>

[Yili Zhao]

对于GUI，可能和操作系统关系更大。至少目前Mac OS X上面应该用Objectvie-C，Windows上面用C++ / MFC /
WTL，或者C#/WinForms/WPF（如果是Windows 8，是不是还要考虑Metro和WinRT），Go语言在这个方面还不适合。

我记得好像谁还曾经说过Go语言的图像库中关于创建图像对象的方法也不止一种（有3到4种），还是构造函数来得统一一些。

想听听大家的看法。

2012/3/9 Liigo Zhuang <com....@gmail.com>:

> “make与new的存在”，我也想再吐吐槽。现在Go语言里创建对象的办法，大概有四种：new, make, struct literal,
> special func。假设某个pkg公开了一个struct A，怎么创建A类型的变量？我要先去文档里查查有没有 NewA()
> 之类的函数，如果有，一般来说你就不能用new(A)或A{...}这类方法初始化。这里又牵涉出Go对象没有构造函数的问题，正是因为没有构造函数，所以不能轻易使用new(A)或A{...}。如果核实了库作者没有提供NewA()函数，你就只能用new或A{...}；等将来那个库升级又添加了NewA()，你旧代码还可能创建出未正确初始化的变量（编译器还没能力编译警告）。真是纠结。反而没有直接调用构造函数省心。

--
Yili Zhao

[minux]

2012/3/9 Liigo Zhuang <com....@gmail.com>

“make与new的存在”，我也想再吐吐槽。现在Go语言里创建对象的办法，大概有四种：new, make, struct literal, special func。假设某个pkg公开了一个struct A，怎么创建A类型的变量？我要先去文档里查查有没有 NewA() 之类的函数，如果有，一般来说你就不能用new(A)或A{...}这类方法初始化。这里又牵涉出Go对象没有构造函数的问题，正是因为没有构造函数，所以不能轻易使用new(A)或A{...}。如果核实了库作者没有提供NewA()函数，你就只能用new或A{...}；等将来那个库升级又添加了NewA()，你旧代码还可能创建出未正确初始化的变量（编译器还没能力编译警告）。真是纠结。反而没有直接调用构造函数省心。

Go希望作为pkg的作者尽可能支持new(A)或者A{}这样方式。

而且尽可能让这样得到的零初始化的变量就是可以直接使用的。

在effective Go里有这方面的建议。

另外，pkg是不应该这样破坏兼容性的升级的，如果设计的时候就充分考虑0值所代表的正确的含义，基本上

是不会在这里做出改变的。

更重要的是，零初始化的值作为有意义的值这个是可以传递的(参见effective Go)，所以实际上Go是根本不建

议有NewA()这样的情况的，标准库里当然有例外，但是你可以单独分析每一个情况就会发现那样是必须的。

[lihui]

同意，我们为客户打的每一个程序补丁也都是必须的。

2012/3/9 minux <minu...@gmail.com>

--

[Dang Allen]

由于喜欢写桌面应用，所以我对于GUI非常关心，目前为止我觉得用Go封装一下win32
api并不困难，关键让我困扰的地方在于“用Go的方式”。没有继承确实带来了很大的麻烦。

[Dang Allen]

另外，我对于binding形式的GUI库表示不乐观。首先我受不了Qt的体积，其次，对于基于OO思想设计出来的库，封装到Go之后处处都会显示出不协调。

[lihui]

没有继承是一个优势，能有效地防止你的类变得无所不包。swing的JMenu有433个方法，你觉得这有意思么？

不过现在每当想构思一个GUI类库的时候，我都走向了设计一个描述界面的声明式语言，然后用引擎解释执行。用看到的某个人得话来说，跟html很像，除了它不是html以外。。。。

2012/3/9 Dang Allen <alle...@gmail.com>

[Dang Allen]

这是我的局限性，因为我从没用过成熟的非OO结构的界面库，脑子里面对于控件和消息机制的规划没有办法在现有Go的规则下有效形成。

[qq wu]

所以我觉得对于GO来说，GUI应该把方向定在 Webkit + HTML + Go。

2012/3/9 lihui <ustc....@gmail.com>

[minux]

2012/3/9 lihui <ustc....@gmail.com>

缺乏一般性的可调用对象的概念——你举个例子说这个吧。

  就是一个对象，可以作为函数来调用。这主要体现在需要回调函数的时候，由于Go中对象不能是可调用函数，因为单方法接口总是比回调函数更加一般（generic）些。所以Go倾向于使用只有一个方法的接口来解决这个问题，并且使用神奇的手法，将与接口方法签名等价的函数转型为满足该接口值。

而在支持可调用函数的语言，如scala、dart中，则不存在这个问题，因此大量的使用函数参数而不是但方法接口。

只能说是单方法接口不太适合这个。但是可调用对象其实本质上就是()的重载。加入这个特性就势必要考虑是否要支持

别的操作符的重载，以及语法。 

但使用单方法接口是痛苦的，其一：闭包函数需要经过一层转换。其二：你不能在函数内部现场定义一个匿名的实现了该接口的类。

为啥不能传递closure过去？很多语言里回调函数就是直接传个函数closure过去呀。(比如Python)

使用closure的性能问题，这倒是不大必要担心。这个和你说的传递一个可调用对象过去我觉得没有

任何本质上的区别。

[Liigo Zhuang]

2012/3/9 laputa <ye.l...@gmail.com>

如果{是否可以单独一行只是个个人口味问题，我觉得可以不用深究。如果编程语言只是个个人使用产品，个性化是更好的选择，但作为团队开发，强制一些规则，能够统一还是统一为好。

有几点不懂，请教一下：）

1. 你自己为“省事”（想投机取巧）而引入的麻烦，还得要自己解决（局部重写编译器吧，这个不怪别人，你前面的工作就没做好）。

因为gc编译器内部实现细节（没有处理到位），导致了 { 不能另起一行。“为保证编译速度”是其中一个理由。其实完全可以从编译器上入手取消这个限制，不应该因为编译器实现方面的内部细节而把这个限制写入语言规范（因为将来很可能会出现更好的编译器，即没有{的限制，也有很快的编译速度）。

 

2. 变量与接口的转换那个问题，在别的语言里怎么没有？还是你自己引入的易混淆的概念。怎么解决？令 var err = nil; return err; 等效于 return nil。

var err = nil; return err; 和 return nil 这两段代码是不等价的，给很多人造成困扰。官方FAQ花费大段文字专门解释这个问题：http://tip.golang.org/doc/go_faq.html#nil_error ，而我越看越糊涂。我认为，修改编译器让两者一致，“保持最小惊讶度”，是最好的办法。如果坚持严格细分两者之间的细微差异，有点走火入魔的意思了，其它有interface的语言都没练到这一层。

[Yili Zhao]

同意。

我看到新闻（http://mobile.51cto.com/team-319531.htm）说豌豆荚1.0版基于.NET框架实现，而2.0版是基于Webkit实现的。

2012/3/9 qq wu <wuq...@gmail.com>:

--
Yili Zhao

[minux]

2012/3/9 lihui <ustc....@gmail.com>

没有继承是一个优势，能有效地防止你的类变得无所不包。swing的JMenu有433个方法，你觉得这有意思么？

同意。一旦有了继承，人一定会陷入试图构造一个完美的class hierarchy的怪圈中不能自拔。但是实际上，跳出来

想想，这一切的一切不都是自己给自己找的事情么？

不过现在每当想构思一个GUI类库的时候，我都走向了设计一个描述界面的声明式语言，然后用引擎解释执行。用看到的某个人得话来说，跟html很像，除了它不是html以外。。。。

然后你会发现现在的GUI库也是在向这个方式(使用一个声明式的语言来描述GUI)靠拢。

然后更多的是GUI里面直接就引入了HTML/CSS的一些特征，所以我还是觉得这最后和Web会

融合。因为和Web App以及本地GUI App最本质的区别是业务逻辑是在本地执行还是远程执行，

但是这个区分已经越来越不重要的，尤其是伴随这PMD的兴起。

[Dang Allen]

这个很有趣！现在正在下载豌豆荚2.0，想要看看运行效果。

[qq wu]

这个就像在 C 语言中，字符串 NULL 和空串的区别。如果你理解了interface，也就不会犯这样的错误。

Go语言的 interface 的非嵌入式设计，是我最喜欢的 Go 语言的特征，也正是因为这样的特征，是避免对象设计复杂化的一个重要原因，也是Go语言中不需要泛型的根本原因。

2012/3/9 Liigo Zhuang <com....@gmail.com>

[minux]

2012/3/9 Liigo Zhuang <com....@gmail.com>

2012/3/9 laputa <ye.l...@gmail.com>

如果{是否可以单独一行只是个个人口味问题，我觉得可以不用深究。如果编程语言只是个个人使用产品，个性化是更好的选择，但作为团队开发，强制一些规则，能够统一还是统一为好。

有几点不懂，请教一下：）

1. 你自己为“省事”（想投机取巧）而引入的麻烦，还得要自己解决（局部重写编译器吧，这个不怪别人，你前面的工作就没做好）。

因为gc编译器内部实现细节（没有处理到位），导致了 { 不能另起一行。“为保证编译速度”是其中一个理由。其实完全可以从编译器上入手取消这个限制，不应该因为编译器实现方面的内部细节而把这个限制写入语言规范（因为将来很可能会出现更好的编译器，即没有{的限制，也有很快的编译速度）。

为啥你非要说这是编译器内部细节没有处理到位呢？还是那句话，你还是提出/实现一个万全的办法来证明这点。

Go Team里面的头几号人物都是做编译器出身的。我觉得随随便便说人家做的东西不会处理不是负责的，除非你

能够用事实(不是用例子)证明你的想法。

这完全不是编译器速度的问题，因为强制所有语句加分号实际上编译器能更快。

另外请注意，是先有的go spec然后Ken Thompson才写的gc编译器，你不要搞混了这因果关系。

(如果你要问这鸡和蛋谁先有的问题，我可以告诉你，最开始ken, r, gri讨论go spec的时候，是Ken实现了一个把Go

翻译到C语言的translator，等到语言规范定型了之后才开始实现gc编译器的)

另外 你在讨论一件事情的时候请一定要考虑实现复杂度以及后期维护你的实现的难度。

2. 变量与接口的转换那个问题，在别的语言里怎么没有？还是你自己引入的易混淆的概念。怎么解决？令 var err = nil; return err; 等效于 return nil。

var err = nil; return err; 和 return nil 这两段代码是不等价的，给很多人造成困扰。官方FAQ花费大段文字专门解释这个问题：http://tip.golang.org/doc/go_faq.html#nil_error ，而我越看越糊涂。我认为，修改编译器让两者一致，“保持最小惊讶度”，是最好的办法。如果坚持严格细分两者之间的细微差异，有点走火入魔的意思了，其它有interface的语言都没练到这一层。

严谨。尽可能不要引入特例。否则你最后一定会被自己引入的特例搞糊涂。 本来这是有解释的，现在引入了一个特例，

以后哪里又引入特别处理…… 如此下去，你的语言一定会无法维护的。

[Dang Allen]

确实，现在DirectUI的思路已经是界面纯粹使用某种配置语言（目前使用xml居多）来描述，然后配合一个高效率的渲染引擎。

[minux]

2012/3/9 qq wu <wuq...@gmail.com>

这个就像在 C 语言中，字符串 NULL 和空串的区别。如果你理解了interface，也就不会犯这样的错误。

Go语言的 interface 的非嵌入式设计，是我最喜欢的 Go 语言的特征，也正是因为这样的特征，是避免对象设计复杂化的一个重要原因，也是Go语言中不需要泛型的根本原因。

re. 这个比喻很好。其实是很简单的一个概念。

[Yili Zhao]

就像金山开源的金山卫士采用的方案一样（http://code.ijinshan.com/）。

2012/3/9 Dang Allen <alle...@gmail.com>:

> 确实，现在DirectUI的思路已经是界面纯粹使用某种配置语言（目前使用xml居多）来描述，然后配合一个高效率的渲染引擎。

--
Yili Zhao

[minux]

2012/3/9 Dang Allen <alle...@gmail.com>

确实，现在DirectUI的思路已经是界面纯粹使用某种配置语言（目前使用xml居多）来描述，然后配合一个高效率的渲染引擎。

然则其实Netscape很早就用这个思路做软件了(XUL+Javascript+XPCOM)。

进一步想，既然HTML/CSS渲染引擎已经这么普遍且随着HTML/CSS的进步已经变得越来越general，

为啥还要再做一套GUI库呢？于是就发现Google的ChromeOS是很有道理的了……

[Dang Allen]

恩，刚刚尝试了一下。豌豆荚2.0的运行效率还是没有DirectUI的方案高，启动时间较长，整个界面的观感带有明显的网页感，内存占用也很高。

在 2012年3月9日 下午8:38，Yili Zhao <pan...@gmail.com> 写道：

[Dang Allen]

也许那是未来，当桌面与网页的界限已经模糊的时候，但不是现在。

[Liigo Zhuang]

2012/3/9 minux <minu...@gmail.com>

2012/3/9 Liigo Zhuang <com....@gmail.com>

我同意 " Worse is better " 。可是，以分号的使用为例：C语言要求所有语句以分号结尾，很明确；Python不需要以分号结尾，也很明确；偏偏GO整出来一个“程序员多数情况下不需要分号结尾，但某些情况下编译器会帮忙加上分号”，而且还把“什么情况自动加分号”大摇大摆地写入语言规范。在这个世界上，不需要以分号结尾的语言多了去了，象GO这样做事情做一半的少之又少，就不能彻底把分号去掉吗？没那么难吧？

因为我既可以使用传统Go风格不写分号，我也可以用分号，把不同语句放到一行。

这是个权衡。你是不可能完全去掉语句的结束符的(也就是;号在C/Go里面的作用)，如果没有，那是因为回车就是。

但是这所谓的隐式结束符就导致你无论如何不能把多个语句放到同一行了。

我举的这个例子的核心是：在分号的问题上，Go语言凭空增加了规则的复杂性（既比C语言复杂，又比Python / JavaScript复杂），却没有带来额外的好处。这种 worse 也是 better 吗？请问 better 体现在哪里？

 

肯定是各有利弊。

再说一点，把自动添加分号写入语言规范怎么了？Javascript也是。

[Yili Zhao]

那是不是可以说：目前Windows下面做客户端软件，如果既要强调运行速度，又要强调内存占用率，最好的方式还是基于DirectUI的方法？

2012/3/9 Dang Allen <alle...@gmail.com>:

> 恩，刚刚尝试了一下。豌豆荚2.0的运行效率还是没有DirectUI的方案高，启动时间较长，整个界面的观感带有明显的网页感，内存占用也很高。

--
Yili Zhao

[Dang Allen]

不是，如果要强调运行速度，又强调内存占用，而对定制界面也没什么要求，那么最好的方式就是使用win32 api。
使用DirectUI除非花钱购买成熟的库，否则开源的几个库包括金山的，对于标准控件类型的支持都不好（比如最常见的listview），里面都只是实现到了刚好可以满足某个特别的应用。

[zhai]

2012/3/9 Liigo Zhuang <com....@gmail.com>

我举的这个例子的核心是：在分号的问题上，Go语言凭空增加了规则的复杂性（既比C语言复杂，又比Python / JavaScript复杂），却没有带来额外的好处。这种 worse 也是 better 吗？请问 better 体现在哪里？

如果你习惯，或者喜欢，可以在一行的代码后加个分号，也是能编译通过的 

[lihui]

为什么不传闭包？

因为前面说了，在没有可调用对象的情况下，单方法接口比函数参数更具有一般性，因此在很多场合你设计api的时候，就不敢用函数参数，而是转而用单方法接口，既然是单方法接口，就不能直接传函数闭包,需要一层魔术变换。一个来自http包中的例子就是 Handler  接口。 

我在设计api的时候，就经常在此纠结。不敢直接用 xxxoo(f func(ResponseWriter, *Request))之类。

2012/3/9 minux <minu...@gmail.com>

--

[minux]

2012/3/9 Liigo Zhuang <com....@gmail.com>

2012/3/9 minux <minu...@gmail.com>

2012/3/9 Liigo Zhuang <com....@gmail.com>

我同意 " Worse is better " 。可是，以分号的使用为例：C语言要求所有语句以分号结尾，很明确；Python不需要以分号结尾，也很明确；偏偏GO整出来一个“程序员多数情况下不需要分号结尾，但某些情况下编译器会帮忙加上分号”，而且还把“什么情况自动加分号”大摇大摆地写入语言规范。在这个世界上，不需要以分号结尾的语言多了去了，象GO这样做事情做一半的少之又少，就不能彻底把分号去掉吗？没那么难吧？

因为我既可以使用传统Go风格不写分号，我也可以用分号，把不同语句放到一行。

这是个权衡。你是不可能完全去掉语句的结束符的(也就是;号在C/Go里面的作用)，如果没有，那是因为回车就是。

但是这所谓的隐式结束符就导致你无论如何不能把多个语句放到同一行了。

我举的这个例子的核心是：在分号的问题上，Go语言凭空增加了规则的复杂性（既比C语言复杂，又比Python / JavaScript复杂），却没有带来额外的好处。这种 worse 也是 better 吗？请问 better 体现在哪里？

我说了好几遍了，就是你一旦掌握这个规则，你可以用分号，也可以不用分号；

你按照规则写，整个程序除了for循环之外不需要分号；你如果觉得太不紧凑，有些地方用用分号把语句弄成

一行也是可以的。

C语言没有这个规则，所以你只有后一个优点；Python也没有分号，且不自动添加，于是你可以按照格式写，

但是不能随意地把一些语句写成一行。

这还是一个折中。

还有这些个规则真的很难记么？你稍微理解下就会发现这个和C语言里NULL和""的去别是类似的，理解后没有

任何啥记忆负担。

[zhai]

http://en.wikipedia.org/wiki/Troll_(Internet) 

Do not feed the trolls 

请哪个英文好的解释一下这个troll怎么编译成中文

2012/3/9 zhai <qyz...@gmail.com>

[minux]

2012/3/9 Dang Allen <alle...@gmail.com>

也许那是未来，当桌面与网页的界限已经模糊的时候，但不是现在。

呵呵  拭目以待了。 

其实在移动设备上这个趋势已经越来越明显了，有多少App其实是基于网页的了？

[laputa]

不知道javascript里的一个例子能不能解释这个问题。

javascript也会自动加入分号，但是是一个很讨厌的行为，例如：

return

{

    status:true;

};

看起来是要返回一个包含status属性的对象，不幸的是，自动插入分号让它返回undefined。所以正确的写法应该是：

return {

    status:true;

};

我觉得Go的设计也算合理，避免出现一些诡异行为。当然，如若换一个方式，就是强制要求加分号。都是强制。

2012/3/9 Liigo Zhuang <com....@gmail.com>

[Yili Zhao]

如果用C语言直接调用Win32 API，还是太麻烦；

如果用C++调用Win32 API，要么自己重新进行封装，
要么使用MFC（但是需要MFC动态链接库的支持），
要么使用WTL。

Dang推荐哪一个？

2012/3/9 Dang Allen <alle...@gmail.com>:

> 不是，如果要强调运行速度，又强调内存占用，而对定制界面也没什么要求，那么最好的方式就是使用win32 api。
> 使用DirectUI除非花钱购买成熟的库，否则开源的几个库包括金山的，对于标准控件类型的支持都不好（比如最常见的listview），里面都只是实现到了刚好可以满足某个特别的应用。

--
Yili Zhao

[Dang Allen]

我不喜欢C++，太复杂。所以选择用Go封装win32
api形成一个小型的GUI库(github.com/AllenDang/gform)，目前我已经开始用它在生产环境写小工具了。
只是我自己对于它的设计思路并不满意，因为走得还是传统的路子，没有充分发挥Go的特点。

[Liigo Zhuang]

2012/3/9 lihui <ustc....@gmail.com>

缺乏一般性的可调用对象的概念——你举个例子说这个吧。

  就是一个对象，可以作为函数来调用。这主要体现在需要回调函数的时候，由于Go中对象不能是可调用函数，因为单方法接口总是比回调函数更加一般（generic）些。所以Go倾向于使用只有一个方法的接口来解决这个问题，并且使用神奇的手法，将与接口方法签名等价的函数转型为满足该接口值。

而在支持可调用函数的语言，如scala、dart中，则不存在这个问题，因此大量的使用函数参数而不是但方法接口。

但使用单方法接口是痛苦的，其一：闭包函数需要经过一层转换。其二：你不能在函数内部现场定义一个匿名的实现了该接口的类。

以前大家都说闭包函数是穷人的对象，但从本质上来说，应该是穷人的可调用对象。 

make和new的存在其根源在于缺乏构造函数而产生的。

赞成，是缺乏构造函数引起的。不只有make和new共存，还有newXXX()和XXX{...}，各种纠结。有了构造函数反而清爽了。

 

ok这种东西，我承认它是有效的，实际上Go的很多设计，都是有效的。不过，一个真正正交的语言，必然是魔幻语言，表示空间绝对地由各特征维度划定，没有被拍扁嘛，scala就是一个经典的例子。

ps：关于那个ok，我一直希望err的返回值也能一样处理（从而更加一致了），即如果存在错误，但用户没有赋值给一个变量检查，就panic，而不是像现在一样，默默无声地运行下去，然后不知道在那一行就挂掉。 go现在鼓励的错误处理方式，比checkedException还要邪恶。

呵呵，如果遇到err就强制panic，那估计没人敢写代码了。现在在Go的标准库里，平均每三行就有类似如下的错误处理：

if err != nil {

    //....

    //这里能做什么处理呢，无非是fmt.Print()或者return err给调用者(然后递归)

}

这种错误处理也太原始了一点，程序员的负担太重了。相比之下还是exception更好一点（至少把正常处理和错误处理隔离开了，不至于把正常的流程都弄的支离破碎）。

2012/3/9 minux <minu...@gmail.com>

2012/3/9 lihui <ustc....@gmail.com>

不仅仅是generic的问题。 generic 在Go上基本是无解的，因为Go在设计之初就是考虑不提供泛型的，这就是为什么map（ 还是个性能杀手） 等东西存在的原因。

不是，他们没找到好的解决办法。 原来roadmap文档上还包括这里呢。这个和对待异常

处理态度真不一样。异常处理那是绝对不会有，这个是还在讨论。

现在最关键的就是性能方面的考虑，参看Russ Cox的这个总结：

The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times?

当然，第二点不应该是and的关系，好的编译器可以不造成binary bloat，但是slow compiler的问题是没办法解决的。

其他不一致的地方有：

hehe  不错 总结了这么多不一致的地方～ 

缺乏操作符重载

哪些操作符允许重载呢？还有这样是否真的有好处？会不会搞得像C++那样超级复杂？

内置类型一概没有方法

这个没啥问题，你只要定义一个alias就能设置方法了。

用Ruby的人估计会有这个体会，如果大家都随意给内置类型加方法，很快就会乱套。

所以内置类型不能添加方法。

至于内置类型为啥没有内置方法的问题，我觉得如果不能定制有哪些方法，那么固定

的一套就容易不够。而且更重要的一点是如果有了内置的方法，这就是语言spec的一

部分了，这东西作为标准库里的函数是可以改的(主要添加)，如果把他们放到语言spec

里去就非常非常不容易改了。(改doc/go_spec.html似乎至少得得到几个核心人物的LGTM

才能通过，标准库的改动就轻松得多)

v,ok:=map[x]中对ok的特殊处理

你是否有更好的处理？改成内置函数？其实我觉得v, ok这样的设计挺符合Go关于错误

处理的一致性的。而且这种处理的好处也很明显，如果你v := map[x]那么也明确表明

你不在乎x是否存在，就像 v, _ := somefunc()这样，明确告知你不愿意处理错误了。

如果设计成一个函数，虽然也可以，但是map类型内置就真没必要了。 

缺乏一般性的可调用对象的概念

你举个例子说这个吧。

对foreach的支持不对用户定义类型开放等等

这是个问题，而且我觉得会要解决的，类似Lua的方式就很好，况且Go是有closure的，

那个方式+Go独有的Interface机制会有比较好的设计的，至少我这么认为，我没看过

关于这个问题的讨论，不知道Go Team是什么态度。 

值变量可以调用指针方法，而interface里的值就不行

我还没仔细想过这个问题的原因。暂时不能评论这个问题。

make与new的存在

是有点郁闷，有了literal的写法之后确实是可以去掉new的。 

以前还有符号的Export和可赋值性强行绑定在一起，WTF！，不过好在现在似乎改过来了。

可以说，Go里面到处充满着特殊处理，不是语言特性之间具有强相关性，就是补丁式的，所以不能理解这个正交性和一致性的说法是怎么来的。

正交性和一致性是语言的设计目标。但是不是唯一或者说最重要的目标。

如果只考虑正交性的话，那语言我估计也就是Ruby比较接近了。性能受的影响太大了，真的。

而且毕竟Go是想作新时代的C语言，有些东西必须得坚持。比如可以让程序员完完整整地控制struct

在内存从的layout等等。所以有些东西还是不能考虑动态的(如果要正交地像Ruby那样的话)

PS: 上面提到了C++, Ruby, Lua等若干种语言，但是我没有任何批评他们的意思。更多的时候是

借鉴他们的设计，毕竟每个语言中都必须要有特定的tradeoff关系。我觉得只有把握了那个语言

设计者考虑的“主要矛盾”才能理解那个语言的某些你觉得诡异的特性。当然，我肯定不是认为Go

现在就是完美的。其实我上面也说了，有几个地方是我也觉得该改进的。

--
来自: Golang-China ~ 中文Go语言技术邮件列表
详情: http://groups.google.com/group/golang-china
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina

[minux]

2012/3/9 lihui <ustc....@gmail.com>

为什么不传闭包？

因为前面说了，在没有可调用对象的情况下，单方法接口比函数参数更具有一般性，因此在很多场合你设计api的时候，就不敢用函数参数，而是转而用单方法接口，既然是单方法接口，就不能直接传函数闭包,需要一层魔术变换。一个来自http包中的例子就是 Handler  接口。 

我在设计api的时候，就经常在此纠结。不敢直接用 xxxoo(f func(ResponseWriter, *Request))之类。

不用闭包更重要的是静态类型方面的考虑，比如sort包的处理，要是动态类型语言肯定是传一个比较函数而不是用interface。

还有一点，就是如果传闭包，一旦封闭就没办法再打开供其他函数访问，而interface就没有这个问题。这个我觉得不是

很好表述，但是我觉得Handler接口是正确的选择(你可能需要保存其他的东西，还要供其他Method访问，如果传递闭包

可就没有这个好处了[就算不考虑type safe以及静态类型])。

[laputa]

嗯，APP Web化是大势所趋。不过不知道这个时间会多久，能否彻底。

另外，潜意识还是觉得在天朝会比较杯具，就像IE6会持续很长时间一样。

网络基础设施和国外差距还是太大。

2012/3/9 minux <minu...@gmail.com>

--

[laputa]

我目前理解panic+recover+defer，是个很妙的设计啊，不需要在函数里，搞一堆try/catch~~

可能我的理解还比较肤浅

2012/3/9 Liigo Zhuang <com....@gmail.com>

[lihui]

panic+recover+defer相当于不需要check的RuntimeException，可能比它还要好些，这点是不错的，当然dart也修复了Java的checkedException的问题。

但 err的方式，就比checkedException还要糟糕了，而Go偏偏最鼓励这一点。

2012/3/9 laputa <ye.l...@gmail.com>

[Jay True]

panic + recover + defer 的方式不适合跨越库边界，貌似是这样的。

[minux]

2012/3/9 lihui <ustc....@gmail.com>

panic+recover+defer相当于不需要check的RuntimeException，可能比它还要好些，这点是不错的，当然dart也修复了Java的checkedException的问题。

但 err的方式，就比checkedException还要糟糕了，而Go偏偏最鼓励这一点。

具体说说？ 

[laputa]

嗯，能否具体讲讲，能有简单的代码示例更好 ^_^

2012/3/9 minux <minu...@gmail.com>

--

[saber]

不懂为什么err的方式会很糟糕呢？

2012/3/9 laputa <ye.l...@gmail.com>