没有这么快。 所有带 gc 的语言都要等一段时间。

原来是 yegger 大神，google 里面唯一一个喜欢 ruby 并坚持使用的 (lisp 也是他的最爱)，不过好像一直布道没有成功，google 里面还是 c/c++,java,python 的占多数。他写东西基本上没有短篇幅的 (把 g+ 当博客用)。。。这篇文章已经非常早了，也算是很有名了。

google group

#52 楼 @peter 不只是四川吧，应该是“红配绿，狗都嫌”。

漂亮了，速度也快了些，但愿不是心里作用。

市面上那些带风扇的散热器除了带来噪音，看不出有什么优点 (不同的笔记本风口和气流方向都有差异，而且外部散热风扇心里作用远大于实际作用)。4 个瓶盖就能解决，再放个小风扇，人和电脑都能吹。

#7 楼 @nightire angular 2 没有什么众怒难平。是 v8 的组比较大，意见不统一： 一票人支持改良 js(后来有了 atscript，atscript= typescript+annotation，typescript 后来决定加入 annotation，于是那票人觉得 atscript 没存在的必要了，和 ts 一起干了)； 另外一票人 (大牛多一些，所以想法更激进吧～～）支持革了 js 的命，于是有了 dart，从设计上都是在解决 js 的痛点 (但很多人说它长得像 java，其实它更像 c#，最新的 dart 1.9 的 await 的设计者，就是以前就在 MS 设计 c# linq 的那位)，但激进的结果是：和 js 互操作性太差，而 js 的库又太庞大，导致 dart 不被接受 (想想 scala 要替代 java 有多艰难吧)。

再回 lz 的疑问： coffee 认为 js 的语法不够漂亮优雅，ts 和 dart 则觉得 js 问题不是语法上的，所以可以说两者对 js 的看法是有差异的，这就是 angular 选择 ts 的原因，而不选 dart 的原因是 angularJS 属于改良派，当然也有 angularDart，只是几乎没怎么见有人用。

从 dart 不再打算内置 vm 进 chrome，看样子是改良派胜利了 2333

#25 楼 @mogodb 放弃没放弃 dart 我也不知道，不过听说他们自己内部有的组在用 dart，事实上 angular2 同时支持编译为 js 和 dart。

Game over: http://blogs.msdn.com/b/typescript/archive/2015/03/05/angular-2-0-built-on-typescript.aspx

#17 楼 @leozwa 据 rust 的人说，今年年底估计会有 1.0。这语言到底怎么样，有了真正的作品出来，从实际使用者的角度来做出评价，到时候就清楚了。

Why Go Is Not Good https://news.ycombinator.com/item?id=7962345 http://www.reddit.com/r/programming/comments/29fp6w/why_go_is_not_good_will_yager/?limit=500 日经吐槽了。

jquery 和 Angular 混用确实有点不伦不类，这两个东西的思考方式是有差别的。 参考这里的精彩回答： https://stackoverflow.com/questions/14994391/how-do-i-think-in-angularjs-if-i-have-a-jquery-background （翻译版）http://www.infoq.com/cn/news/2013/11/how-to-think-angularjs

他说是写操作系统，编译器这些底层的东西，通过手工控制内存可以慢慢的来精益求精，所以不需要 gc，再说了底层的东西变化是非常缓慢的，对性能要求又比较高，所以 gc 用处不大；但对搞定一个任务，快速交付客户，在计算机已经非常快的情况下，这种性能上的损失又是完全可以忍受的情况下，使用 gc 能简化程序员编程，提高你的工作效率，何乐而不为。后面又说了没有一个通用的 gc 算法来处理各种任务，在一些实时任务中可能无法忍受 gc 带来的高延迟，所以需要酌情考虑。总之又回到了："用合适的工具干合适的事情"这个主题中来。这里有必要说说 Erlang，在电话网络这种延迟要求苛刻的环境中使用了 20 多年了，说明 GC 并非不能做高性能的东西，可靠性说不定反而更好。 而对于 c++，其中说到每个公司，每个程序员只用到了 c++ 的一部分子集，而这些子集又是不同的，这里说的非常好。 我个人觉得如果 c++11，14 这些能早出来 8-10 年，就好了。现在 c++ 这种情况属于无解，历史遗留问题太多，但一时半会儿又没有什么语言能替代它，就这么凑合着用着吧。

不要用 /* */，建议全部用//

#48 楼 @yfractal 因为你举的这几个专有名词全部是西方人发明的原生的东西，然后我们再翻译成中文的，当然不好理解了，很多著作中干脆就不翻译一些英文专有名词，因为语言间彼此的转换本身就会损伤精准度，同样我们用中文很简单到位的表达某个意思在英语里要费半天劲。例如“道”，在英文里怎么都找不到对应的词汇，必须辅助一大段话进行解释。

我也觉得如此，只是中文学习曲线比英文陡，尤其是对老外来说。在计算机的世界，全是西方字母的世界，对中文非常不利，用电脑时间长了对老外没啥影响，但我们的中文书写理解能力却大幅下降。hacker news 上面有老外说英语和编程关系太紧密了，导致现在的编程语言逻辑性和正确性存在问题。 另外就是做搜索，翻译，语音识别的这些搜索公司对自然语义的处理上，中文也是最难处理的。google 的翻译在西方各个语种间翻译转换已经很准确了，但中英文转换还是非常差。这说明中文确实比英文要严谨或者说更复杂 (至少从机器去 parse 的角度上去看，是这样的)。

#116 楼 @bhuztez 那些都已经超过了语言本身的界限，例如 c++ 通过 sse2 指令实现的 2 叉树可以比 c 的快。这个网站的测试有很多限制条件，有很多的实现版本未必会被采纳。c 很多情况下不如 fortran 这个老古董快倒是事实，但是也只限于 intel 的硬件上。

我觉得动态解释性语言，函数式编程语言要想在实际中达到理论上所描述的那样性能最终超越 c 还很遥远，haskell 的一些专家也承认在很多情况下 c 写的代码更便于优化出更好的性能。我觉得要超越 c，现在这种冯诺依曼架构的机器得发生大的变化，至少得向 lisp 机方向靠近一些，还有就是得等人工智能的技术有所突破才行。现在的编译器和人其实就是两对矛盾体，都在要求电脑给自己提供更大的方便。

#64 楼 @luikore Go 的源代码 tools 目录下有个 SSA 就是专门给编译器用的，所以说 Go 的“编译器设计就已经给自己划定了极限”似乎不妥。另外别忘了还有 gccgo 和 llgo(llvm 后端的 Go 编译器，有人在开发这个)。

#58 楼 @luikore google c++ 编译慢的问题 google 的一个工程师在 hacker news 上面解释过，现在已经不是什么问题了，c++11 比以前好了不少，他们也的确采用了其中你提到的部分做法，更多的原因可能是以前的 c++ 代码树确实太老了，rob pike 那时候接触的时候看到的情况可能和现在情况已经不同了。也有一个可能就是两个人在 google 负责 c++ 那个巨大的代码树的不同部分，可能看到的结果不一样。 我个人对 c++ 谈不上喜欢更谈不上讨厌，只是觉得 c++ 太复杂，坑也太多了点，c++ 社区的人很擅长也非常流行重复造轮子，boost 就是想缓解这个问题。也许是我太笨，估计搞一辈子也不能了解到 c++ 的皮毛。 另外 Rust 受关注少那是因为 Rust 到现在连正式版都没有发布，api 和语言本身不停的再变，根本没法用到生产环境中去。而 Go 现在用在生产环境中的例子已经不少了，github 上面的 repos 数目也很多。Go 1.0 发布之前也就 09 年借着 google 的光环火了一下子，从那以后销声匿迹，直到 12 年 1.0 版本发布这才慢慢谈论的多了起来。google 自己真正的亲儿子 Dart 到现在也不见有多少关注 (也没有发布正式版)。

#16 楼 @luikore GC 可选——GC 简单，减轻程序员负担，性能未必差，最好的例子当然是 lisp 了，王垠说那个商业化的 chez scheme 编译器性能极高。 Ruby-like lambda——compile time type safe 如何保证？静态编译语言比灵活性肯定比不了 ruby； 动态链接——arm 上已经可以了，x86/64 上也快了。各种依赖的地狱让我在想：我们必须使用动态链接的情况现在还是非常普遍吗？直接扔一个二进制过去 just work 不好么？ 异常——纯属个人口味问题，Go 支持多返回值 (Lua 也是如此)，两者都推崇错误值，另外异常在并发多线程编程中效果又如何呢？另外 Go 的 defer/panic/recover 就是 Go 的异常。 除了 let 和 ; 以外都是表达式——好像 Go 很多情况下更推崇 statement，同样考虑的目标不同； 模式匹配和无 null——模式匹配，Go 的做法是用 swtich.(type)，这样不需要搞复杂语言本身的类型系统，simple。not-null 这个讨论都快把 golang-nuts 撑爆了，最终还是决定使用 nil，简单说还是 trade-off 的结果，最近看王垠的一篇博客说使用 null 本无错，应该是当初使用 null 的这些语言的类型系统搞得不好，才出现了这个 billion dollar mistake。 macro——很强大很管用，但只在少数情况下的确如此。Go 的风格肯定是避免这类东西的，还有 dsl 这些等等。 不需要为用不到的语言特性买单——Go 就是如此。 泛型函数——目前没有，以后会不会加不清楚。我写 Go 代码时，确实遇到过没有泛型不方便的地方，说实话我也非常希望看到这个东西。

#22 楼 @rasefon 二叉树对比测试，那个网站的作者说：目的是测试 gc，不允许使用任何第三方和自定义的 pool，而 c 语言的实现版本却使用了 pool 有作弊嫌疑，有人使用 slice 实现了一个版本的二叉树，在那个网站的单核 32 位评测下，C 的速度是:12.84,Go 的速度是:14.24，相差无几 (链接： http://benchmarksgame.alioth.debian.org/u32/program.php?test=binarytrees&lang=go&id=6)， 可是那个网站评测作者拒绝采纳，更多细节可以去 golang-nuts 讨论。 #19 楼 @luikore Go 1.1 相比之前版本性能提升非常明显，你可以抽空试试。Go 现在的 gc 和调度器还比较落后 (相比 jvm)，gc 到 1.3 才会成为 100% 精确的 gc，而有了精确的 gc 才有实现分代、压缩，可移动 gc 的可能，这些都在不断开发中 (想想 ruby 都多少年了最近的 2.1 才宣布实现了分代式的 gc，汗～～搞 gc 的人才真不好找)，调度器目前也只有函数实体实现了抢占式调度，所以底层编译器这些优化的还有很多，这些都是影响性能的关键，所以性能这东西说实在的还得靠时间去优化，比的就是编译器效率，静态编译的语言发展到最后性能应该不是问题。相比 llvm，6g/8g 还有很多工作要做，另外一点：Go 编译器的其中一个设计目标是快速的编译速度，这个可能会影响编译出代码的性能，具体看以后的优化程度了，像 llvm 这种，目前已经优化到极致，JVM 也是优化了 10 多年了，JIT 技术也非常成熟了，Go 目前比这些肯定要差点。但差 C 语言 10 倍，这个不太可能，可以 pprof 一下 Go 代码找出瓶颈，部分测试情况下出现 2-3 倍还可以接受。

@huihen 现在是 java+scala 好像还有一些 FP。

erlang 果然牛 x，不过 golang 迟早要赶上来，哈哈。

原来很多人以为 amazon 仅仅是个卖书的呀～～

用 google 的服务准备梯子是必须的。

python-cn 用户组那里人气较高，订阅之后，每天打开你的收件箱就知道有多壮观了。另外 v2ex 也不错。

刚好我去书店时大致翻阅了这本书。Matz 主要介绍了 Go,dart,coffee script,lua 以及 node.js。对 Go 介绍的篇幅相对是最多的，在未来的新出现的语言中他本人最为看好这个。对于 Dart，他本人偏向于不看好，主要出于两方面：1.dart 想替代 js 很难，因为其他公司不会主动去支持 dart，同时 js 也会慢慢进化来抵消 dart 的语言优势。而且要建立一个生态圈也不是一朝一夕的事。2.Dart 综合了动态语言和静态语言的特性，提供可选的类型，Matz 本人是动态语言的坚定支持者，所以他反对这种做法，认为既没有彻底的得到动态语言的高效开发效率的同时又丧失掉了静态语言性能和静态分析很多方面的优势。但最后他又给出了结论说：编程语言就是这种时间周期很长，变化发展很缓慢的东西 (10 多年时间)，所以 dart 能否成功他自己也说不准。 我倒是觉得如果 dart 能变成一个更好的 java 还是挺不错的，弥补了 java 在并行编程以及 web 化一些方面的缺陷，例如 dart 里面的 web UI 应该是比较新的玩意，贴合了这些年 web 前端开发一些不断出现的技术，到目前为止还没有前端和后端使用同一种语言的，dart 能到达这个目标就算成功了。

这几年似乎 google 出的几个东西争议都很大：Go 对比 mozilla 的 Rust，Dart 之于 harmony 的 JS 改进，pnacl 对比 mozilla 的 asm.js。

应该说是最好的 c/c++ IDE。其他方面 jetbrains 是神器。

别着急着下结论，出去逛逛开阔下眼界也不错。