rust 的 issue 数都突破 10000 了... go 还只有 600 多

#12 楼 @hlxwell 是很微小

require 'benchmark'; s='1' * 1000_000_000; puts Benchmark.measure{s.count '1'}
  0.780000   0.000000   0.780000 (  0.778674)

@hlxwell 你本来的问题是什么？可能针对那个问题有更快的解决方案。但是用了这样的存储方式没法快了...

#9 楼 @bhuztez 数据库也要读硬盘的啊

瓶颈在你把数据读出来需要的时间，而不是计算方法

str.count '1'

结果单位是弧度，转成角度即可

Math.asin(0.5) * 180 / Math::PI

内存要够大 (readme 说 1.8G), 否则碰到 swap 就慢了 ^_^

#2 楼 @wppurking 很多 c++ 实现的部分用 rust 重写了，meta-circular bootstrap 都要经历的 -_-

#4 楼 @iBachue 不用线程和 EM, 就只能放到队列里了，更麻烦... 或者试试 celluloid

#28 楼 @kiol mac 下以前不能 -_- 还有各种 bug

在新 thread 里做也不会 block 的

#113 楼 @astaxie

1. 彻底对 70000 行无语了，你也不看看 /E 选项是做什么的...
2. 代价非常大，花了我好几分钟...
3. 你是在假设 C++ 程序员都不知道编译器输出的 warning: foo unused 是什么意思？
4. 这篇文档根本就不是讲语法的啊！(跑题一下，go 的 func 语法根本没美感可言，我是强迫症患者，top level 不能写 func literal 让我抓狂...)

关于语法的一些陈述不太对。一般是先设计语法，然后细化 parser. 优化的做法是减少回溯或者需要 look ahead 的部分，对于 CFG 系列的 (LL, LR, GLR 等) 语法不精细的地方，解决方案就是找会有二义性的点添加断言，并写进 spec 里表明哪一种更优先。go 里只有把类型写在后面的语法是有利于 parsing 的，但那是其他语言长时间得来的经验，也不是 go 特有的。应该说 go 根本就没花多少心思在设计语法上。

我同意你降低心智的说法...

@sunfmin 这两贴把 go 程序员都钓出来了，还要招人么？

#96 楼 @chai2010 70000 行是哪里来的 -__-

1. include 的问题可以用 stdafx/pch 解决，现在很多 C++ 编译器已经优化过 include 了，还拿好多年前的状况来说事...
2. 与其说 Go 减少 pkg 的依赖，不如说 Go 的 pkg 比 C++ 少太多，当引入的 pkg 达到相同数量级的时候问题还是会出现。
3. C++ 在未定义的处理上更人性化，打开 -Werror=unused 同样可以禁止定义未使用变量 (不止是变量，还有很细粒度的控制). 最终集成 build 打开就可以，开发时那种限制就是恶心人。C++ 编译速度和链接速度是可以自己做主的，如果想忽略掉链接期优化，关闭编译器开关即可，链接就快多了。但是 Go 的设计决定就把需要链接期优化的人都一竿子打死了。
4. C++ parser 的二义问题都已经解决了。Go 的语法哪里便于优化？

其实 git 命令行也能做行内的 diff

[color "diff"]
  old = black red
  new = black green
[alias]
  d = diff --color-words='[^[:space:]]+|.'

#69 楼 @astaxie 撸撸睡了... 晚安

#66 楼 @astaxie 我很早就回过了，再指明白一点吧：因为你的测试用了四年前的 GCC, 而且优化选项开得比较低

虽然我不想再把 go 比 ruby 慢的测试贴翻出来...

#61 楼 @astaxie 你对 ruby 的说法是错的。说明你完全不了解也不想去了解 ruby.

2006 版 rust 对应的应该是 limbo 而不是 go 的 2007 版...

program that writes program 才是语言发展的王道，不管语法还是编译器都是这样进化的，没有元编程能力显然是倒退...

#63 楼 @astaxie 别激动... 理论上 Go 就不太可能接近 C 的速度。

现在的主流 C 编译器中，GCC 和 LLVM 都有一个叫做 IL 的东西，IL 是 intermediate language 的缩写， Go 的编译速度主要是去掉了 IL 和链接期优化而来的 (应该说 Go 是有 intermediate representation, 但还很原始简单没上升到 intermediate language 的高度).

GCC, LLVM, Java, C# 性能优良的原因之一，就是有设计良好的 IL. GCC 的其中一层 IL Gimple 就是个 lisp 方言，由于 lisp 程序员眼里没有语法，只有语法树，所以 lisp 用来处理树和 DAG 等结构也是比较得心应手... Java 的 IL JVM bytecode, C# 的 MSIL 都是基于栈的简单语言。LLVM 的 bytecode 是个无限寄存器制的 SSA 语言。

IL 作为可读代码可以简化编译器开发 debug 的工作，可以归一化平台无关的优化，没有 IL 的话很多平台就要用相似但不同的代码实现一些优化逻辑，偏门一点的平台就容易出 bug. 不过由于 Go 的作者有多年的 Inferno OS 开发编译器的经验，Go 才没有发生很多问题，但是在这个基础上的发展肯定会比拥有 IL 的语言慢很多。链接期优化也是 IL 的主要作用之一，例如 clang -S -O4 的输出就是 LLVM IL 而非汇编，得到所有 IL 以后再来做变换，获得更好性能。javac 和 csc 编译的输出也是 IL.

抽象层次高的代码，编译器可以做的优化就越多，运行时优化也比编译期优化的空间大。搞编译器的朋友表示动态语言理论极限会比静态语言快... Go 的编译器设计就已经给自己划定了极限...

#51 楼 @astaxie Go 里很多都是 20 年前 Inferno OS 的旧东西... 这几年 Ruby 里添加的新东西也有很多哦，建议你了解一下。Rust 作为比 Go 更新更好的语言，受到的关注却有点太少了，还不是没有 google 干爹的缘故。

如果 Go 相关的新闻里都没有 "Google" 字样，首先记者发这个消息的动力就会少一半，然后读者关注度更加大打折扣... 所以就算作者说和 google 没关系，市场受到 google 影响是显然的。

#49 楼 @astaxie 不了解 C/C++ 不要瞎说... 是 google 的 C++ 项目编译太慢了 lol, 其实就是拆分好模块，用动态链接就能解决，另一方面是 google 内部广泛应用的 protobuf 生成的代码大量应用了 C++ 模板进一步增加了编译时间，protobuf 作者后来设计的 capnproto 就没这个问题。对于 C 准确来说是 C89 之前的表达能力有欠缺，但经过 C99, C11 的改进，表达能力 (dynamic array, inner function, type-generic macro, thread 等等) 已经强多了。C macro 的问题，由于编译器改进，追踪 macro 中的问题已经比 30 年前容易多了。而没有 macro 的 Go, 很多情况比 C 的表达能力还弱 -_-.

#39 楼 @reus 我表示包挺好，测试没有 assert 不贴心，调优是必须的...

&& (@health < warrior.health) ---> && (@health == warrior.health)

#36 楼 @bhuztez 至少不是碰到个问题就三重 for 拍上去... 好吧 Go 的目标是取代 C 在 Web 开发中的地位...

我碰到过 nginx 不在启动时自动加载的问题，sudo 拷贝到 /Library/LaunchAgents/homebrew.nginx.plist 然后 chomd 644 就可以了。

但是第一次访问正常而第二次失败很诡异... log 怎么写的？

#28 楼 @Numbcoder 有关系哦，你看见有几个 Go 的使用者会用这些函数？不少人实现了发现用起来根本没 Ruby 的一半方便就放弃了回到 for 循环里了

#26 楼 @bhuztez 我是从这个角度看的：static suffix-typed C-like with local type inference ... 最初 Go 的目标也是 C++, 不过是服务器端 C++, 后来没吸引到 C++ 程序员就转到动态语言用户群中挖角了

#22 楼 @Numbcoder 可以无缝使用 C/C++ 的 lib 啊

#23 楼 @bhuztez curly brace 密度上相似...

#19 楼 @gaicitadie 对啊，这个拼爹社会里人的认识受各种因素影响，反而失去了对事物本身的判断能力...

就语言本身设计来说

web 开发，如果一个语言不支持元编程，没有 map, reduce, each_slice, find ... 等函数，写复杂业务逻辑就是噩梦...

相似的语言的话，Rust 设计得更好，相比 Go 的各种优点：

• GC 可选，性能甩 Go 一条街
• Ruby-like lambda and do block
• 动态链接
• 异常
• 除了 let 和 ; 以外都是表达式
• 模式匹配和无 null
• macro - 可以自己搞各种字面量，web 完全是个拼字符串的世界，没有正则表达式字面量玩个毛
• 不需要为用不到的语言特性买单
• 泛型函数