我为什么放弃Go语言
982 views
Skip to first unread message
Viney Chow
Apr 14, 2014, 10:54:22 PM4/14/14
to golang-china
我为什么放弃Go语言
看来Liigo伤的很深，好久没看他发言了。
------------------------------------------------------
Viney
Blog:http://nanhaizh.cn
Github: http://github.com/viney
Facebook: http://facebook.com/VineyChow
Twitter: http://twitter.com/VineyChow
Weibo: http://weibo.com/VineyChow
E-mail: viney...@gmail.com
刘鑫
Apr 14, 2014, 11:05:19 PM4/14/14
to golang...@googlegroups.com
无所谓啦，本来就是个工具语言，没必要人人都去拜。对自己好用，就用实际行动来支持，这不比打嘴炮好多了。从来没有一门编程语言能让所有人都满意。何况人家文章里有些东西写的还是挺有道理。特别是社区的态度问题。去年我说某IDE的插件不能识别不可达的逻辑，一大群人出来教育我说go语言本来就这么设计的。只有巢鹏一个人的博客上写着这是go官方2009年就明明白白列出来的一个bug。现在不但那个bug修掉了，我要是再写同样的代码，go的工具还会发警告……
--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛中的“Golang-China”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAJnE2OxhnNVqRHZ4A45TOGt2h%2BwChm7fRPRKMbPRzezgjnBi1A%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。
……
劉鑫·矮人工匠
Mars Liu @ Dwarf Artisan
marschant
Apr 14, 2014, 11:11:27 PM4/14/14
to golang...@googlegroups.com
赞一下作者，至少其中两条我绝对赞成
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CACGJLu4qhCNz0QVPrUDvhsMXG0R-ps4tK2mkQ6rS_9VLFZqd7A%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。
--
never give up,never never never --0x55aa
Yang Fan
Apr 14, 2014, 11:12:35 PM4/14/14
to golang...@googlegroups.com
感觉文章作者主要不满来自于人际交往。至于列出来的那些语言方面的问题，在我看来大多数反而是go的特色，作者是照着C++/C#/JAVA在说我要什么我要什么。只有少数确实是问题如GC，不过不也在改了么。
Regards,
Fan Yang
Larry Li
Apr 14, 2014, 11:14:46 PM4/14/14
to golang...@googlegroups.com
对于花括号的怨念，作为了 PHP 程序员，长长的 psr 指南在团队中实施真的很难。
不实施 psr，git merge 就是一个灾难。
在 2014年4月15日 上午11:05，刘鑫 <marc...@gmail.com>写道：
minux
Apr 14, 2014, 11:18:47 PM4/14/14
to golang...@googlegroups.com
On Apr 14, 2014 10:54 PM, "Viney Chow" <viney...@gmail.com> wrote:
> 我为什么放弃Go语言
> http://blog.csdn.net/liigo/article/details/23699459
> 看来Liigo伤的很深，好久没看他发言了。
不存在一种语言能适合每个人，恩。
早点意识到某个语言不适合自己是个好事。（如果意识到之后不去对应的列表 trolling 就更好了。）
在不适应所有人这个问题上，Go 比其他的语言更严重，因为Go作者们非常“顽固”，在他们认为的原则问题上绝不让步。所以Go终究只能适应和他作者意见一致（或者至少是能够理解）的人。不过幸好作者们的意见一般是对的。
尽管 Go 支持 Windows，而且我也认识一些在 Windows 上开发 Go 或者用 Go 开发的人，但是理解 Go 还是需要先理解 Unix（最好是 Plan 9）的设计理念。
刘杰
Apr 14, 2014, 11:22:48 PM4/14/14
to golang...@googlegroups.com
只对错误处理那一点儿赞同，其他的方面觉得作者个人色彩浓重。
--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛中的“Golang-China”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
sanye
Apr 14, 2014, 11:24:43 PM4/14/14
to golang...@googlegroups.com
On Tue, 2014-04-15 at 11:12 +0800, Yang Fan wrote:
> 感觉文章作者主要不满来自于人际交往。至于列出来的那些语言方面的问题，在
> 我看来大多数反而是go的特色，作者是照着C++/C#/JAVA在说我要什么我要什
> 么。只有少数确实是问题如GC，不过不也在改了么。
>
同意。另外，作为c程序员，我很喜欢defer，再也不担心直接return而fd忘记关的
问题了。他说的那种应用场景用defer明显不合适。
> 感觉文章作者主要不满来自于人际交往。至于列出来的那些语言方面的问题，在
> 我看来大多数反而是go的特色，作者是照着C++/C#/JAVA在说我要什么我要什
> 么。只有少数确实是问题如GC，不过不也在改了么。
>
同意。另外，作为c程序员，我很喜欢defer，再也不担心直接return而fd忘记关的
问题了。他说的那种应用场景用defer明显不合适。
jianxiao jiang
Apr 14, 2014, 11:27:41 PM4/14/14
to golang...@googlegroups.com
我比较赞同这些
1.6 禁止未使用变量和多余import
1.7 创建对象的方式太多令人纠结
1.8 对象没有构造函数和析构函数
1.10 许多语言内置设施不支持用户定义的类型
1.11 没有泛型支持，常见数据类型接口丑陋
- 版本都发展到1.2了，goroutine调度器依旧默认仅使用一个系统线程。GOMAXPROCS的长期存在似乎暗示着官方从来没有足够的信心，让调度器安全正确的运行在多核环境中。这跟Go语言自身以并发为核心的定位有致命的矛盾。
您收到此邮件是因为您订阅了 Google 网上论坛的“Golang-China”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
要在网络上查看此讨论，请访问 https://groups.google.com/d/msgid/golang-china/1397532283.23250.6.camel%40rms。
要查看更多选项，请访问 https://groups.google.com/d/optout。
minux
Apr 14, 2014, 11:28:15 PM4/14/14
to golang...@googlegroups.com
2014-04-14 23:05 GMT-04:00 刘鑫 <marc...@gmail.com>:
无所谓啦，本来就是个工具语言，没必要人人都去拜。对自己好用，就用实际行动来支持，这不比打嘴炮好多了。从来没有一门编程语言能让所有人都满意。何况人家文章里有些东西写的还是挺有道理。特别是社区的态度问题。去年我说某IDE的插件不能识别不可达的逻辑，一大群人出来教育我说go语言本来就这么设计的。只有巢鹏一个人的博客上写着这是go官方2009年就明明白白列出来的一个bug。现在不但那个bug修掉了，我要是再写同样的代码，go的工具还会发警告……
能否说一下是对应讨论的主题？
到底是关于IDE的插件还是关于 gc 编译器的？我不太认为关于 IDE 的插件的讨论能引出 ”Go语言就是这么设计的“
的回复。
以及，我大胆的猜测一下，是关于 return 语句的问题？
刘鑫
Apr 14, 2014, 11:33:02 PM4/14/14
to golang...@googlegroups.com
对，就是这个
--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛中的“Golang-China”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
Monnand
Apr 14, 2014, 11:42:43 PM4/14/14
to golang中文组
Liigo这人根本就是一个喷子。搜一下此人在这个列表上的言论就看得出来。反正我很早就把他的邮件列在黑名单里，完全无视他的言论。
跟一个编程语言能这么较劲实在是让人非常无语。看Liigo在列表上乱喷就跟看一个人对着一把螺丝刀发脾气一样，让人非常哭笑不得。再加上此人用词刻薄，这就显然不招人喜欢了。
跟一个编程语言能这么较劲实在是让人非常无语。看Liigo在列表上乱喷就跟看一个人对着一把螺丝刀发脾气一样，让人非常哭笑不得。再加上此人用词刻薄，这就显然不招人喜欢了。
--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛中的“Golang-China”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
chai2010
Apr 14, 2014, 11:52:08 PM4/14/14
to golang中文小组
没有语言能是完美的, Go也是一样.
作者提到 "很多言行都是“反开源”的。", 我到觉得开源软件集权的好处远大于坏处.
开源主要给你的是fork的权利.
比较认同的几点抱怨:
1.3 极度强调编译速度，不惜放弃本应提供的功能
1.8 对象没有构造函数和析构函数
1.10 许多语言内置设施不支持用户定义的类型
1.11 没有泛型支持，常见数据类型接口丑陋
编译速度快是好事, 但是如果因为编译速度而严重影响语言的特性设计就不好了.
不知道后面的 语言内置类型和泛型 支持限制是否是受编译速度的限制.
关于资源析构, 之前cgo中, 都是用 runtime.SetFinalizer 来增加一层保障.
但是前几天 golang-dev 居然有人讨论要干掉 runtime.SetFinalizer ...
我觉得最不爽的地方还是在泛型/运算符重载/内置的特权类型等方面.
当然 IDE 也是很让人不爽的一个地方.
最后, 最喜欢的还是Go的简洁但不简单.
minux
Apr 14, 2014, 11:52:33 PM4/14/14
to golang...@googlegroups.com
2014-04-14 23:27 GMT-04:00 jianxiao jiang <jiangj...@gmail.com>:
我比较赞同这些
1.6 禁止未使用变量和多余import
1.7 创建对象的方式太多令人纠结
1.8 对象没有构造函数和析构函数
1.10 许多语言内置设施不支持用户定义的类型
1.11 没有泛型支持，常见数据类型接口丑陋
- 版本都发展到1.2了，goroutine调度器依旧默认仅使用一个系统线程。GOMAXPROCS的长期存在似乎暗示着官方从来没有足够的信心，让调度器安全正确的运行在多核环境中。这跟Go语言自身以并发为核心的定位有致命的矛盾。
对于 GOMAXPROCS 的问题，参看 http://golang.org/doc/faq#Why_no_multi_CPU
”版本都发展到1.2了，goroutine调度器依旧默认仅使用一个系统线程。”
这个不确切。即使 GOMAXPROCS == 1，也可能创建任意多（受限于 runtime/debug.SetMaxThreads 的限制，默认 10k）
的系统线程的（只是任意时刻只有一个线程能执行Go 代码而已），而且也不一定只有一个线程在执行，比如 cgo 或者
GC 都是能够让 GOMAXPROCS == 1 的 Go 进程使用超过 1 个 CPU 的。
“GOMAXPROCS的长期存在似乎暗示着官方从来没有足够的信心，让调度器安全正确的运行在多核环境中。这跟Go语言自身以并发为核心的定位有致命的矛盾。“
这个推论就完全错误了。即使是 GOMAXPROCS == 1，Go 的调度器也是完全 concurrent 的。
而且关于 runtime 调度器的优化的工作都是同时比较 GOMAXPROCS == 1, 2, 4, 8, 16, 32
下的性能的。
确实，GOMAXPROCS > 1 的话存在 data race 的问题，但是这完全跟调度器无关，存在 data
race 的程序本身结果就是 undefined（在 C++ 11 里面其实也是这么说的）。默认设置 GOMAXPROCS
为 1 跟这个一点关系也没有。
之所以 GOMAXPROCS 默认是1，主要的原因是，concurrent != parallelism。不是所有 Go
程序在 GOMAXPROCS > 1 都能提速的，参见 http://golang.org/doc/faq#Why_GOMAXPROCS
如何让 runtime 自动设置 GOMAXPROCS 来达到最佳的性能是个困难的研究课题。
（注意到，程序的执行 pattern 是会改变的，如何知道何时应该提高 GOMAXPROCS?
另外，channel 的用法有非常多的模式，如何让调度算法自动适应每个模式？还有优化
的目标是什么？很多情况下最低响应延迟和最大系统吞吐量是不可兼得的，如何让用户
选择/影响优化目标？
恩，如果你还觉得这个问题很简单，那恭喜你，欢迎仿真并在 golang-dev 发布你的设计
文档。不过我个人建议你先把这个算法写成论文发表。）
Go 目前做的是尽可能优化 GOMAXPROCS 在一定范围内（1~32或者64?）的 runtime
性能，然后由用户决定到底用几（一般需要 benchmark 才能知道）。
鉴于对于不同的应用的 GOMAXPROCS 的最佳值不确定，官方也不建议在 .bashrc 之类
的地方设置全局 GOMAXPROCS > 1。
Bluek404
Apr 14, 2014, 11:57:13 PM4/14/14
to golang...@googlegroups.com
《我为什么放弃治疗》
这个世界上没有什么东西是完美的，Go已经做的很好了
--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛中的“Golang-China”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CA%2Bdb%3Dn0uK%2BJQybk2b4ijsP2ZMFSqaCz6gu4rizscxoX6YUc56g%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。
Viney Chow
Apr 15, 2014, 12:14:14 AM4/15/14
to golang-china
------------------------------------------------------
Viney
Blog:http://nanhaizh.cn
Github: http://github.com/viney
Facebook: http://facebook.com/VineyChow
Twitter: http://twitter.com/VineyChow
Weibo: http://weibo.com/VineyChow
E-mail: viney...@gmail.com
在 2014年4月15日 上午11:42，Monnand <mon...@gmail.com>写道：
Liigo这人根本就是一个喷子。搜一下此人在这个列表上的言论就看得出来。反正我很早就把他的邮件列在黑名单里，完全无视他的言论。
我说呢，怎么没看他发言。 我觉得对于这篇文章，我们要以取其精华去除糟粕的眼光去看待。
mikespook
Apr 15, 2014, 12:15:23 AM4/15/14
to golang中文组golang中文组
1. 如果我不再想关注一个技术，一般不会再去撰文，特别是这么长的文章。
2. 阅读后，一个感觉 Go 还停留在 1.0 之前，另一个感觉 Go 是个纯 OO 的语言。
3. 错误认知通常会伴随沟通障碍。而建立在这两者之上的讨论大多都不怎么有意义。
4. minux 坚持在OT帖里谈技术，这是一种什么精神？
5. 千万不要撰文: 我为什么坚持…
minux
Apr 15, 2014, 12:17:24 AM4/15/14
to golang...@googlegroups.com
ft 我本来克制自己不去看这篇文章，不过看来都被引用过来了。不过既然
有人赞同，就值得讨论一下。
2014-04-14 23:52 GMT-04:00 chai2010 <chais...@gmail.com>:
没有语言能是完美的, Go也是一样.作者提到 "很多言行都是“反开源”的。", 我到觉得开源软件集权的好处远大于坏处.开源主要给你的是fork的权利.
开源软件有很多种运行模式。其中比较主要的一种就是独裁似的。纵观开源社区，
很多著名的项目都是最终核心的一个人，或者几个人有绝对的话语权。
（实际上也不存在一个成功地开源项目是完全民主的。连 committee 设计的东西
都不是完全民主的……）
如果被动地接受每个意见，那么项目很容易丧失方向性，导致各种各样的特性被
加入，但是没有一个人在总体上把握特性之间的交互。对于一个编程语言，这点
更为重要。
一个好的开源项目领导者要能说 No。
比较认同的几点抱怨:1.3 极度强调编译速度，不惜放弃本应提供的功能
恩，强调编译速度是个特性。但是并不意味着 Go 会放弃优化（我假设优化是
属于这”本应提供的功能“之一。Rob 也说了，以后 gc 会提供 SIMD 优化。
1.8 对象没有构造函数和析构函数1.10 许多语言内置设施不支持用户定义的类型1.11 没有泛型支持，常见数据类型接口丑陋编译速度快是好事, 但是如果因为编译速度而严重影响语言的特性设计就不好了.不知道后面的 语言内置类型和泛型 支持限制是否是受编译速度的限制.
泛型的支持总是被人拿出来说事儿。关于泛型的支持，官方唯一说的就是在等一个
完美的设计。倒不全是编译速度上的考虑。
关于资源析构, 之前cgo中, 都是用 runtime.SetFinalizer 来增加一层保障.但是前几天 golang-dev 居然有人讨论要干掉 runtime.SetFinalizer ...
不是没同意么。Dmitry 完全站在 GC 实现者的角度考虑这个问题，不免有失偏颇。
顺便说一点，他说的 SetFinalizer 的问题一个都没有错，只不过一般情况不会遇到
或者很容易避免罢了。
我觉得最不爽的地方还是在泛型/运算符重载/内置的特权类型等方面.
运算符重载绝对不会有，这是个特性，不是 bug。
内置的特权类型是因为没有泛型。泛型要想有很大可能得等 Go 1.2，假设能有人
设计出来一个完美的泛型设计。参看 http://research.swtch.com/generic。
（虽然基本上每个月在 golang-nuts 列表上都会有人宣称某个语言同时解决了文中
提到的3个问题，但是没有一个能给出具体的解决方式的，最终的讨论都归结于：
”XX 语言解决了所有的三个问题，至于怎么解决，你自己去看它的实现“）
当然 IDE 也是很让人不爽的一个地方.
这个等社区了。要知道作者们是觉得 Acme 就足够了的。
不过最近 go.tools 的发展很欣喜。Go 在语法上设计的优越性终于慢慢被 adonovan
和 gri 等发掘出来。最新的进展比如 godoc -analysis type 还有 eg，这些都将是 IDE
的核心组件。作者们大多不是搞 GUI 的（虽然 Rob 开发过若干 GUI 程序，但是他搞
的和我们理解上的 IDE 这种 GUI 完全不是一会儿事儿），所以他们能为 IDE 做的
就是提供这些基础结构，至于 UI，那就没办法帮忙了。
PS: 没有试过 godoc -analysis "type,pointer" 的人强烈建议安装即将发布的 Go 1.3
beta。完完全全不一样的体验。（唯一的问题是需要很多内存。）
最后, 最喜欢的还是Go的简洁但不简单.
恩 我也喜欢这个。设计一个超级复杂的系统简单（能否正常工作不一定……），
但是设计一个简单的能正常工作的系统就很难了。
（C++ 就是一个反例，C++ 很强大，但是有多少人完全理解 C++11 的方方面面？
如果我不能全部理解 C++11 标准，我如何参与 C++ 的项目？
大多数 C++ 的开源项目都刻意限制了某些 C++ 结构的使用，为什么？）
minux
Apr 15, 2014, 12:28:07 AM4/15/14
to golang...@googlegroups.com
2014-04-15 0:15 GMT-04:00 mikespook <mike...@gmail.com>:
1. 如果我不再想关注一个技术，一般不会再去撰文，特别是这么长的文章。
2. 阅读后，一个感觉 Go 还停留在 1.0 之前，另一个感觉 Go 是个纯 OO 的语言。
3. 错误认知通常会伴随沟通障碍。而建立在这两者之上的讨论大多都不怎么有意义。
恩 我第一个回复就表达了类似的说法，如果无法理解和赞同 Go 作者的理念，是很难
喜欢这个语言的。不过你这个说法太专业了！
4. minux 坚持在OT帖里谈技术，这是一种什么精神？
啊，我压根没意识到这个主题的定位是 OT。不过我觉得从这个主题来看，对 Go 语言
及其开发存在着一些普遍的误解，还是借着这个抢眼的主题尽可能解释清楚比较好。
5. 千万不要撰文: 我为什么坚持…
其实撰文不要紧，别发到 Go 相关的列表里就好。
steve wang
Apr 15, 2014, 12:36:34 AM4/15/14
to golang...@googlegroups.com
On Tuesday, April 15, 2014 12:28:07 PM UTC+8, minux wrote:
2014-04-15 0:15 GMT-04:00 mikespook <mike...@gmail.com>:1. 如果我不再想关注一个技术，一般不会再去撰文，特别是这么长的文章。
2. 阅读后，一个感觉 Go 还停留在 1.0 之前，另一个感觉 Go 是个纯 OO 的语言。
3. 错误认知通常会伴随沟通障碍。而建立在这两者之上的讨论大多都不怎么有意义。恩 我第一个回复就表达了类似的说法，如果无法理解和赞同 Go 作者的理念，是很难喜欢这个语言的。不过你这个说法太专业了！4. minux 坚持在OT帖里谈技术，这是一种什么精神？
啊，我压根没意识到这个主题的定位是 OT。不过我觉得从这个主题来看，对 Go 语言及其开发存在着一些普遍的误解，还是借着这个抢眼的主题尽可能解释清楚比较好。
这种误解或者说是偏见，基本上是根深蒂固的，我估计很难短时间内消除。
对于一些人，可能要随着编程阅历的增加逐渐改变对go语言的看法；还有一些人，可能一辈子也没法改变看法了。
chai2010
Apr 15, 2014, 12:37:30 AM4/15/14
to golang中文小组
运算符重载和泛型比, 没有也不算大的问题.
之前看过rsc的泛型文章, 说实话还是喜欢C++的方式.
但是rsc说C++的方式会: "This slows compilation."
难道这个不是他们抵制这种方式的原因吗?
看了你的回复, 感觉泛型和IDE都都盼头了...
--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛中的“Golang-China”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
steve wang
Apr 15, 2014, 12:55:25 AM4/15/14
to golang...@googlegroups.com
运算符重载是我坚决反对的。。。
难道这个不是他们抵制这种方式的原因吗?
看了你的回复, 感觉泛型和IDE都都盼头了...
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到golang-china+unsubscribe@googlegroups.com。
丛峻峰
Apr 15, 2014, 1:00:20 AM4/15/14
to golang...@googlegroups.com
这种东西真心觉得没有什么在邮件列表中讨论的必要。很多东西都是见人见智的。
作者嫌弃c的一些特性，我还先期COBOL的一些特性呢。可是现在的C语言如何？COBOL又如何？不一样被证明是优秀的么？
在语言层面，想要一些，就必定会放弃一些。你就是再牛逼的算法，最终不也得在空间与时间中平衡么。
再者说，如果有一天，go能够为开发者带来其他语言不能带来的收或者BOSS说了，要么go，要么滚，你们看作者会不会再坚持他所谓的放弃。
发件人: steve wang steve....@gmail.com
回复: golang...@googlegroups.com golang...@googlegroups.com
日期: 2014年4月15日 at 下午12:55:29
到: golang...@googlegroups.com golang...@googlegroups.com
邮件标题: Re: [gocn:11645] 我为什么放弃Go语言
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/5b8df769-632b-483e-a1e7-1aa157db77be%40googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。
--
丛峻峰
Sent with Airmail
丛峻峰
Sent with Airmail
minux
Apr 15, 2014, 1:08:00 AM4/15/14
to golang...@googlegroups.com
2014-04-15 0:37 GMT-04:00 chai2010 <chais...@gmail.com>:
运算符重载和泛型比, 没有也不算大的问题.之前看过rsc的泛型文章, 说实话还是喜欢C++的方式.但是rsc说C++的方式会: "This slows compilation."难道这个不是他们抵制这种方式的原因吗?
还有 bloated binary 吧。就我个人来说，我也认可 C++ 的方式。对于 Go 或许
有办法来解决这个问题（C++ bloated binary 我以为是两个原因：
1, 即使是内存里面结构相同的的不同类型T1和T2，std::vector<T1>和std::vector<T2>
会生成两套实现；
2. 大多数目前使用的 C++ 依赖于传统的链接器，所以 C++ 编译器必须假设每个可能
用到的 template 都得例化，然后依赖链接器去解决重复定义的问题。但是这个不是万能
的，rsc 的文章里提到的取消/重新规整 template 之后 .text 从若干 MB 减少到 几十 KB
就是例子。
Go 不完全依赖普通的链接器，而是拥有自己的链接器，所以其实是可以部分解决第二个
问题的（template 会导致过度的 inlining，这个问题靠独立的链接器解决不了），但是第
一个问题就比较麻烦了。
我的感觉是，相对其他方式，C++ 这个是唯一 Go 能接受的实现方式（用最常见的例子，
max 函数来说，我就是希望对于不同类型例化完全独立的函数，也就是有一部分二进制
体积的增长是不可避免的，相对现在手工提供maxInt32, maxFloat64来说，这个其实是
一样的）。但是有几个问题
必须解决：
1. binary bloat
2. template 不是在某种意义上说不是 type safe 的。Go 显然不会引入 C++ concept 来解
决这个问题。（e.g. 使用一个 template 的时候，如果不展开 template 的内容，无法知道
使用是否正确；这里似乎是使用 interface 的好机会）
3. 如何把设计和现有的 Go 特性（尤其是interface）完美地融合和交互？
我相信编译器的速度不是大问题，具体的语法也不是大问题。
（当然，不能像 D 语言那样做一个 Turing complete 的 generics 系统。换句话说，编译时
要做的事情必须是 bounded 的，也就是存在高效的实现方式）
看了你的回复, 感觉泛型和IDE都都盼头了...
我非常确定的一点是，Go 对 IDE 的（底层）支持会越来越好。
（对于 IDE 感兴趣的一定要关注 go.tools sub-repository。
Go Oracle, godoc, eg 这些都可以用来做 IDE 的。）
泛型完全取决于能不能有人提出满意的设计。（这个比较难）
我不知道放弃Go的文章提到没有，调试器的问题。他们决定
要彻底放弃 gdb，据说，**仅仅是据说**，然后给 Go 开发一个新的。
IDE 的问题绝对不是他们不重视，实际上 http://golang.org/ref/spec#Introduction
就提到了：
The grammar is compact and regular, allowing for easy analysis by automatic
tools such as integrated development environments.
gri 和 adonovan 看来是在专职做这方面的事情。（相比完整的 IDE，具备一个 refactor
工具，即使是命令行工具，是重要得多的事情）
chai2010
Apr 15, 2014, 1:25:26 AM4/15/14
to golang中文小组
在 2014年4月15日 下午1:08，minux <minu...@gmail.com>写道：
2014-04-15 0:37 GMT-04:00 chai2010 <chais...@gmail.com>:运算符重载和泛型比, 没有也不算大的问题.之前看过rsc的泛型文章, 说实话还是喜欢C++的方式.但是rsc说C++的方式会: "This slows compilation."难道这个不是他们抵制这种方式的原因吗?还有 bloated binary 吧。就我个人来说，我也认可 C++ 的方式。对于 Go 或许有办法来解决这个问题（C++ bloated binary 我以为是两个原因：1, 即使是内存里面结构相同的的不同类型T1和T2，std::vector<T1>和std::vector<T2>会生成两套实现；
之前看image包的接口, 发现对于 Gray16 等是采用不依赖字节序的方式处理的:
// Pix holds the image's pixels, as gray values in big-endian format ...
如果是采用C++的泛型方式, 这里应该是用和机器序相关的 uint16.
想请教下, 如果以后 Go 采用类似 C++ 泛型, image.Gray16 这种设计是不是和泛型冲突的 ?
2. 大多数目前使用的 C++ 依赖于传统的链接器，所以 C++ 编译器必须假设每个可能用到的 template 都得例化，然后依赖链接器去解决重复定义的问题。但是这个不是万能的，rsc 的文章里提到的取消/重新规整 template 之后 .text 从若干 MB 减少到 几十 KB就是例子。Go 不完全依赖普通的链接器，而是拥有自己的链接器，所以其实是可以部分解决第二个问题的（template 会导致过度的 inlining，这个问题靠独立的链接器解决不了），但是第一个问题就比较麻烦了。我的感觉是，相对其他方式，C++ 这个是唯一 Go 能接受的实现方式（用最常见的例子，max 函数来说，我就是希望对于不同类型例化完全独立的函数，也就是有一部分二进制体积的增长是不可避免的，相对现在手工提供maxInt32, maxFloat64来说，这个其实是一样的）。但是有几个问题必须解决：1. binary bloat2. template 不是在某种意义上说不是 type safe 的。Go 显然不会引入 C++ concept 来解决这个问题。（e.g. 使用一个 template 的时候，如果不展开 template 的内容，无法知道使用是否正确；这里似乎是使用 interface 的好机会）3. 如何把设计和现有的 Go 特性（尤其是interface）完美地融合和交互？
现在有人在做这个设计吗? Go2是不是可能会解决泛型的问题?
我相信编译器的速度不是大问题，具体的语法也不是大问题。（当然，不能像 D 语言那样做一个 Turing complete 的 generics 系统。换句话说，编译时要做的事情必须是 bounded 的，也就是存在高效的实现方式）看了你的回复, 感觉泛型和IDE都都盼头了...我非常确定的一点是，Go 对 IDE 的（底层）支持会越来越好。（对于 IDE 感兴趣的一定要关注 go.tools sub-repository。Go Oracle, godoc, eg 这些都可以用来做 IDE 的。）泛型完全取决于能不能有人提出满意的设计。（这个比较难）我不知道放弃Go的文章提到没有，调试器的问题。他们决定要彻底放弃 gdb，据说，**仅仅是据说**，然后给 Go 开发一个新的。IDE 的问题绝对不是他们不重视，实际上 http://golang.org/ref/spec#Introduction就提到了：The grammar is compact and regular, allowing for easy analysis by automatictools such as integrated development environments.gri 和 adonovan 看来是在专职做这方面的事情。（相比完整的 IDE，具备一个 refactor工具，即使是命令行工具，是重要得多的事情）
感谢你提供的信息.
--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛中的“Golang-China”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
minux
Apr 15, 2014, 1:44:43 AM4/15/14
to golang...@googlegroups.com
2014-04-15 1:25 GMT-04:00 chai2010 <chais...@gmail.com>:
在 2014年4月15日 下午1:08，minux <minu...@gmail.com>写道：2014-04-15 0:37 GMT-04:00 chai2010 <chais...@gmail.com>:运算符重载和泛型比, 没有也不算大的问题.之前看过rsc的泛型文章, 说实话还是喜欢C++的方式.但是rsc说C++的方式会: "This slows compilation."难道这个不是他们抵制这种方式的原因吗?还有 bloated binary 吧。就我个人来说，我也认可 C++ 的方式。对于 Go 或许有办法来解决这个问题（C++ bloated binary 我以为是两个原因：1, 即使是内存里面结构相同的的不同类型T1和T2，std::vector<T1>和std::vector<T2>会生成两套实现；之前看image包的接口, 发现对于 Gray16 等是采用不依赖字节序的方式处理的:// Pix holds the image's pixels, as gray values in big-endian format ...如果是采用C++的泛型方式, 这里应该是用和机器序相关的 uint16.
这个真不好说啊。不过就这个例子来说，我觉得应该改成 uint16。
目前那个就是为了满足同意的接口吧。
想请教下, 如果以后 Go 采用类似 C++ 泛型, image.Gray16 这种设计是不是和泛型冲突的 ?
所以 Go 1 是不可能有泛型的，Go 2 如果能有泛型，大部分标准包估计得重新设计。
设计泛型的时候也得考虑如何最大可能地兼容 Go 1 的程序……
2. 大多数目前使用的 C++ 依赖于传统的链接器，所以 C++ 编译器必须假设每个可能用到的 template 都得例化，然后依赖链接器去解决重复定义的问题。但是这个不是万能的，rsc 的文章里提到的取消/重新规整 template 之后 .text 从若干 MB 减少到 几十 KB就是例子。Go 不完全依赖普通的链接器，而是拥有自己的链接器，所以其实是可以部分解决第二个问题的（template 会导致过度的 inlining，这个问题靠独立的链接器解决不了），但是第一个问题就比较麻烦了。我的感觉是，相对其他方式，C++ 这个是唯一 Go 能接受的实现方式（用最常见的例子，max 函数来说，我就是希望对于不同类型例化完全独立的函数，也就是有一部分二进制体积的增长是不可避免的，相对现在手工提供maxInt32, maxFloat64来说，这个其实是一样的）。但是有几个问题必须解决：1. binary bloat2. template 不是在某种意义上说不是 type safe 的。Go 显然不会引入 C++ concept 来解决这个问题。（e.g. 使用一个 template 的时候，如果不展开 template 的内容，无法知道使用是否正确；这里似乎是使用 interface 的好机会）3. 如何把设计和现有的 Go 特性（尤其是interface）完美地融合和交互？现在有人在做这个设计吗? Go2是不是可能会解决泛型的问题?
据我所知，Go team 没人做这个。（既然只有 Go 2 才能有泛型，而 Go 2 还比较遥远，现在
该做的是把 Go 1 做到最好。）
我记得我昨天说过 1.4 和 1.5 的展望。大体就是，Go 要完全变成用 Go 写的（从工具链到 runtime）。
gccgo (gofrontend) 要改成支持 非 gcc 后端（换句话说就是要支持 LLVM 做后端，当然，在这
之前，llgo 要切换到 gccgo 目前的 runtime: libgo，这样 llgo 就能完整支持 Go 语言，然后就可以
开始优化了。gccgo 也会是类似的计划，先把后端独立出来，然后优化。（不过提醒一下 gccgo
那边只有 2 个人。）
vfc
Apr 15, 2014, 2:43:17 AM4/15/14
to Golang-China
在 2014年4月15日 下午1:08，minux <minu...@gmail.com>写道：
--
go.tools功能确实很强大，liteide的最新版本x22就是使用go.tools来做的分析器，从而实现find usages和refactor/rename symbol under cursor 。
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛中的“Golang-China”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
Yang Fan
Apr 15, 2014, 3:05:46 AM4/15/14
to golang...@googlegroups.com
歪个楼。liteide有没有todo list或泛点的roadmap？
--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛中的“Golang-China”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAJUoX_N-RZHLnaS9Od%3D08MujZQv4sqnyRWarLqczXxXo%3DpCHww%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。
Regards,
Fan Yang
菜鸟001
Apr 15, 2014, 5:06:36 AM4/15/14
to golang...@googlegroups.com
太偏激！
在 2014年4月15日星期二UTC+8上午10时54分22秒，viney写道：
zhen Gao
Apr 15, 2014, 5:29:37 AM4/15/14
to golang中国邮件列表
里面说的析构这块， 都有GC了，析构拿来干什么用？
--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛中的“Golang-China”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
曹贤
Apr 17, 2014, 1:41:27 AM4/17/14
to golang...@googlegroups.com
只对不支持动态库赞同其他的根本就不是问题,你说的那些真的太扯了.
Shark Flh
Apr 17, 2014, 11:32:20 PM4/17/14
to golang...@googlegroups.com
似是而非，以煽情为主
qq510371827
Apr 18, 2014, 4:12:37 AM4/18/14
to golang...@googlegroups.com
这文章引起了老外的注意：why is Golang popular in china？
我觉得Liigo有必要再写篇英文版的Go rant去澄清一下。
在 2014年4月15日 上午10:54，Viney Chow <viney...@gmail.com>写道：
我为什么放弃Go语言
看来Liigo伤的很深，好久没看他发言了。------------------------------------------------------VineyBlog:http://nanhaizh.cnGithub: http://github.com/vineyFacebook: http://facebook.com/VineyChowTwitter: http://twitter.com/VineyChowWeibo: http://weibo.com/VineyChowE-mail: viney...@gmail.com
--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛中的“Golang-China”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
Bluek404
Apr 18, 2014, 11:49:20 AM4/18/14
to golang...@googlegroups.com
这闹得挺严重了
于 2014年04月18日 16:12, qq510371827 写道:
这文章引起了老外的注意：why is Golang popular in china？
我觉得Liigo有必要再写篇英文版的Go rant去澄清一下。
在 2014年4月15日 上午10:54，Viney Chow <viney...@gmail.com>写 道：
David DENG
Apr 26, 2014, 11:40:45 PM4/26/14
to golang...@googlegroups.com
做个不恰当的比喻：暗恋上了一个女神，可是一直不被接纳，结果还慢慢的发现女神很多地方其实自己并不能接受，还不肯按照自己喜欢的方式改，终于有一天决定不在一棵树上吊死，走出来了。福哉？祸哉？
我想说的是，语言不是用来崇拜或者痴迷的，不要当成女神，要当成韦小宝一样的好朋友来看。文章中提到的缺点我基本上都认为是 Go 的优点；关于 feature 的取舍方面，我刚用的时候也在 golang-nuts 上提过不少建议，应该基本上都被否决的，不过我最后佩服的是开发者对于自己信念的坚持。我个人是一个写程序很有洁癖的人，因此对于 Go 里面各种看似过于严格其实非常合理的限制很满意，呵呵。
David
On Monday, April 14, 2014 7:54:22 PM UTC-7, viney wrote:
zhen Gao
Apr 28, 2014, 2:35:55 AM4/28/14
to golang中国邮件列表
我也觉的一个语言限制越严越好，这样会提高开发效率，你想想，当一个需求可以用几十种写法实现，并且相互没有非常明显的好坏时，而这时又有几个始终觉的自己是真理的人在开发组。。。。
最明显的就是花括号在是不是另起一行的问题， 其实另不另起一行都可以，只要统一就好，GO光这项，就省了多少无胃的争端。
--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛中的“Golang-China”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
marschant
Apr 29, 2014, 6:05:50 AM4/29/14
to golang...@googlegroups.com
呵呵，我觉得你们和作者笔下的那帮人没啥区别
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAKHox9pG6O9jd4ErsFt0vDVSXPyhcGnSf3%2BVzoEAS6_tB1Lj1A%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。
--
never give up,never never never --0x55aa
Yang Fan
Apr 29, 2014, 8:02:24 AM4/29/14
to golang...@googlegroups.com
确实没区别，但关键问题是作者批判那帮人的理由站不站得住脚？
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAN%3DS4tqDAfxT%2BRhLyKmn-TQkGgN-sCZKrLvLrhrxrsk%3DH4vQcw%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。
--
Regards,
Fan Yang
B.Tag
Apr 29, 2014, 11:19:04 PM4/29/14
to golang...@googlegroups.com
看到他是搞E语言的，果断忽略。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAHf7%2BKo66hnes73WN96OxGuyK2nUXCS5etSb_%2ByZAOsGM4Z7sA%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。
----------
个人
Reply all
Reply to author
Forward
0 new messages