第 0 章已经被删除了，如果需要的话请参考《WebAssembly 标准入门》： https://github.com/chai2010/awesome-wasm-zh/blob/master/webassembly-primer.md

感谢大家的支持。准备抽奖送 3 本图书。

需要有 github 账号，然后到抽奖链接的 issue 回复，给出自己的幸运号即可。 截止时间暂定为 12.31 号。

抽奖链接： https://github.com/3dgen/cppwasm-book/issues/4

另外，我们针对 C/C++ 用户提供了一个开源的教程《C/C++ 面向 WebAssembly 编程》： https://github.com/3dgen/cppwasm-book

欢迎关注

#99 楼 @luikore 忘了说一点了，Go 的 pkg 变化不会导致间接依赖的 pkg 被重新编译。如果你是用 stdafx.h 的机制，那每次在 stdafx.h 改点代码之后，编译时间会很痛苦吧。

#113 楼 @astaxie 70000 行只是说明每个源文件编译时都要展开很多重复的代码，如果有很多源文件，这是很浪费编译时间和硬盘空间的。include 和模板都是编译器的速度杀手。

#99 楼 @luikore

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 的语法哪里便于优化？

70000+ 是 VC2010 的结果，VC2012 已经是 80000+ 了：

cat helloworld.cc #include

int main() { std::cout << "Hello, World!" << std::endl; return 0; }

cl /E helloworld.cc >helloworld-cc.txt 用于 x86 的 Microsoft (R) C/C++ 优化编译器 17.00.60610.1 版版权所有 (C) Microsoft Corporation。保留所有权利。

helloworld.cc

wc -l helloworld-cc.txt 84316 helloworld-cc.txt

1. stdafx/pch 已经说明了 include 的问题，只是在补救而已。再说如果代码在不同模块之间，你愿意每个源文件被 stdafx/pch fuck 一次吗？
2. 你还没有理解我说的意思：如果 pkg 在一定数量之后，C/C++ 的每个库绝对会被 include 多次，而依赖是树形结构，这个是指数的差别。
3. 又是一个语言的问题，要靠编译器私活帮忙的例子。你说的方法是语言标准吗，VC 用户怎么办？Go 语言如果需要运行速度的话，可以期待 gccgo 的版本 (这个运行速度优先级是高于编译速度的).
4. 在解决二义问题时浪费了编译时间没有？

#71 楼 @luikore gcc 的 o2/o3 差别不大，有个别的 o3 还不如 o2 快。

#22 楼 @rasefon

go 比 c 慢 10 倍的场景并不少见，比如二叉树测试：

你知道这个测试为什么 Go 比 C 慢 10 倍吗？你看过 2 个语言的测试代码没有？ 我是看过的。C 语言是基于 apr 的 pool 实现，而已还开启了 openmp 优化 (这是标准 C 语言吗？). Go 语言是基于 GC(不可否认 Go 语言的 GC 性能确实还有优化的余地), 如果也改用 pool 实现 Go 的测试就和 C 持平 (17 和 15 的差异).

各种实现的对比在: http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=binarytrees

Pool 的实现代码在: http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=go&id=6

这个测试的性能很不公平，因为 C 使用了 apr_pool 和 openmp. 那如果用 Go 写个汇编或 opencl 的版本是不是也可以呢？

#19 楼 @luikore Go 编译器的性能在 2012 年底已经和 C 很靠近 (GCC 测试 10% 差距). 但是，Go1.1 和 1.2 在 runtime 和很多库的改进还是很大的 (包含网络部分). LLVM 是很厉害，有些测试也可以甩 GCC 很多。

#10 楼 @luikore Go 有些库的性能确实比不完全是 C 写的极端优化的库性能要慢很多. 但是，拿这个来证明 Go 语言比 C 语言慢 10 倍就比较扯了。

#95 楼 @bhuztez

搞编译器的朋友表示动态语言理论极限会比静态语言快...

动态语言和静态语言有区别？

估计只有被伊莫金人聚能的码农才能写那种理论极限的编译器

#76 楼 @AReverie 我也觉得楼主是在黑 Ruby.

#58 楼 @luikore C++ 编译慢的原因: 一个 C++ 版本的 helloworld, VC2010 展开后是 70000 行. 怎么能不慢？

Go 编译快的原因：

1. import 代替 include, 防止了头文件展开导致的代码指数增长。
2. Go 禁止 import 未使用的 pkg, 减少了 pkg 的依赖
3. Go 禁止定义未使用的变量，减少了类型的依赖 (也就减少了 pkg 的依赖)
4. Go 语法规则便于编译器实现和优化 (且少了很多歧义)

#6 楼 @gaicitadie 不要混淆编程语言和网络服务的概念。使用 Go 语言又不需要 Google 的服务器支持. 代码就在那里，难道 Google 关闭 golang.org 网站就会导致语言消失吗？

楼主这样想，只能说明楼主根本不了解 Go 语言的背景. 在 2009 年 Go 语言刚刚发布时，确实吸引了很多不明真相的用户和很多脑残记者，并且还获得 TIOBE 的年度语言，排名最高 13 名。

在 2009 年，除了因为 Google 而关注 Go 语言的用户外，还有很多是因为 Ken Thompson/Dennis M. Ritchie/Rob Pike 而关注 Go 语言. 因为 UNIX 文化而关注 Go 语言的人不在少数，而且觉得不是光靠 Google 光环就能忽悠得了的， 我想因为 UNIX 而关于 Go 语言的人很多已经在使用了。

Go 语言的哲学和 C 语言一样 (和 UNIX/C 是一脉相承的), 都是短小精悍. 这类语言并不是要像Java/C#那种要庞大团队支撑的. Rob Pike 他们的 Bell 小组就足够了。

而且，Go 本身确实是在尽量回避 Google 的光环。golang.org 没有 Google 的字样. Go 语言完全是 BSD 的协议，即使 Google 完全开除了 Go 的开发团队了， 难道 Ken Thompson/Rob Pike 他们还会真的失业吗？

PS:

1. C 语言之父 Dennis M. Ritchie 也是 Limbo 的粉丝，具体看他写的 Limbo 语言规范: http://doc.cat-v.org/inferno/4th_edition/limbo_language/limbo

2. Limbo 是语言的亲爹，但是 Go 的并发背景却是有久远的历史的. 最早从 UNIX 的管道 (其实在 UNIX 之前就有类似的思想), 到 CSP 的理论， 到 Newsqueak(Rob Pike 1989), 到 Alef(Phil Winterbottom 1993), 然后就是 Limbo 和 Go. 其中，只有 Alef 和 Go 是 C-like 的，但是 Alef 只有 Plan9 短暂支持. 我觉得 Go 语言是这类语言的真正回归 (我比较喜欢 Go 中和 Alef 类似的并发思路).