好好玩转 Ruby 挺好的

你错了

这个还是看社区，google 是否有能力创建一个社区。sun 买 mysql 的原因就在与 mysql 后面的社区，用户数太大了。

按照 Slashdot 的风格，这个帖子下面应该有一堆

[citation needed]

其实说到弃坑 M$ 那边的也有不少。。

大约在 08 年的时候，google 出了一套在线协作系统，铺天盖地的媒体公关文，号称要革 email 的命，互联网的下一代 XXX，一时间网上都在求邀请码注册个帐号，朋友也发给我一个邀请码，还发给我一个 pdf 文档，用来学怎么使用这套系统的。一套需要读文档才能玩的转的系统，注定是要悲剧的，果然没过多长时间，google 宣布放弃这个项目了，说是太先进太超前，以至于不被网民接受云云。。。现在我都记不起那个项目的名字了

#6 楼 @gaicitadie 09 年的 google wave?

还有一个系统，貌似是类似 disqus 的那种给网站提供评论服务的，google 的公关文说是要革 im 的命，革 qq、oicq 的命，后来也没有下文了。经历的次数多了，就对 google 的这些项目免疫了。要革 facebook 命的 plus 项目现在也半死不活。

google 是个追求金钱的商业公司，就是再高尚也得追求金钱，并且 google 的风格是短期带来效益，如果短时间内不能带来效益，google 是没有耐心放长线钓大鱼的。这点还不如微软，微软至少对自己的产品支持的周期要长一些，google 说扔就扔，没商量。

google 对自己产品的态度就像押宝，押对了就继续投入资源 (比如 android)，押错了就把它扔一边任其自生自灭

好吧，我本来都在 rubylearning 上报了课程了，果断被楼主骂醒

go 是个开源项目，就算 google 不维护了，肯定会有人继续维护 另外，学习 go 没有坏处吧

我是觉得他确实很有趣才学的

支持楼主，我觉得一个人的精力有限，手上用熟悉一种语言再说，如果真的遇到了这个语言都无法解决的瓶颈，那说明你成功了，你已经有大笔大笔的钱，可以招青年才俊帮你去解决了。

程序员容易陷入技术里面去，如果是自己创业的话，重要的是想法和运营。

#6 楼 @gaicitadie 在线协作不是整合到 Google Drive 里面了么？ 你说的 Wave 已经被人接手了 https://rizzoma.com/topic/

如果 Google 是一个平庸的公司，也不会去想着革谁的命了。

真的没必要浪费心思在这个 topic

盖茨说的对！

还真不觉得几个大佬是一时头热才做这个项目的

#16 楼 @luikore 赞同，map reduce filter curry .....

#16 楼 @luikore 学 rust 的时候很有 ruby 的感觉，写起来很舒服很人性化，只是他的爹不如 go 的爹牛气，从新浪微博一搜竟然还有很多说 rust 不如 go 人性化的，这是个拼爹的社会

Go 的代码缺乏美感。

https://github.com/astaxie/beego/blob/master/controller.go#L3-L22

https://github.com/astaxie/beego/blob/master/controller.go#L343-L359

Taste 很重要啊。

看看 Rust

fn main() {
    let nums = [0, 1, 2, 3];
    let noms = ["Tim", "Eston", "Aaron", "Ben"];

    let mut evens = nums.iter().filter(|x| **x % 2 == 0);

    for &num in evens {
        do spawn {
            let msg = fmt!("%s says hello from a lightweight thread!",
                           noms[num]);
            println(msg);
        }
    }
}

Rust 在最近几个版本里面 API 改动很大，以前写个 println 搞得跟 Java 一样 io::println .

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

Rust 貌似发展很缓慢，社区也不太活跃。各种工具，lib 都很少。现在想在产品环境用，恐怕不行。

#16 楼 @luikore Rust 和 Go 怎么能说是相似呢，目标都不一样...

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

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

#23 楼 @bhuztez Rust 目标是 C++ Go 目标是 Ruby Python 或者 C 想做 Web 的...

#24 楼 @luikore 类 C 的语法都差不多吧。问题是 Rust 和 Go 语义上差别也太大了。

#22 楼 @Numbcoder Rust 都还没发布正式版呢...

#16 楼 @luikore map, reduce, each_slice, find ... 等函数，不是可以自己实现吗，语言核心级别不提供也没关系吧？

#16 楼 @luikore

动态链接

动态链接是个 bug ...

不需要为用不到的语言特性买单

让人想起了 C++

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

#30 楼 @luikore

Go 的目标是 System Programming，Go 的目标是要革 C 在应用开发的命

Rust 的目标是写浏览器，Mozilla 很保守，就是把已经研究得比较充分的语言特性能拿过来试试，能比 C++ 好一点就可以了。

#25 楼 @Saito 只要有相关的库，rust 开发 web 未尝不可，会比 go 舒服的多，至于 rust 复杂的那部分，开发应用可以无视它，光用它简单的那部分已经比 go 顺手多了。静态编译语言，竟然能有写 ruby 的感觉，非常难能可贵

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

你这帖子也太符合分类了……

Go 本来就是一帮 C/C++ 程序员尝试用来代替 C/C++ 的……我认为它已经做到了 A better C 但如果你的喷点在于做 web 开发……我也认为这不是 Go 适合的领域……就像正常人不会用 C 写 web 一样……

至于 Rust……语法蛋疼成这样也有人说人性化？我反正无法接受……

#34 楼 @Kabie Rust 语法都没最终确定呢

#33 楼 @luikore 搞得好像 Rust 不用 for 一样的

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

#37 楼 @luikore 我没说 Web...

这种讨论，就像争论长矛和大刀哪个更厉害一样。 不会有结论的。

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

#41 楼 @luikore 尤其是 pprof 的 http 接口，太良心了 http://yard.reus.me:55555/debug/pprof/

就目前来说，go 还是不错的。ruby 虽好，但为什么都差不多 20 年了，人们才发现它的好。以后的事还很难说的。

http://www.haskell.org/haskellwiki/Wadlers_Law

关于 Google 对 golang 的支持， 前段时间听了个 podcast，Rob Pike 说其实 go 一直跟 G 公司关系分得很清，比如 golang 网站上都没出现过 google 字样（有心跟 Angularjs 官网对比一下），他到希望 G 公司能多给点支持。不过，他又说，现在就算没有 google 支持项目仍然可以发展下去，而且 google 内部目前用的也不多。

最八卦的一点是，golang 的 Windows 移植部分主力是中国程序员干的

Podcast 在这里

顶 rust

#34 楼 @Kabie 我记得 Go 当初是说应对 Web 而生的

一群人瞎喷，首先 Go 是开源项目，目前虽说主力开发的人还是 Google 的为主，但是你去看看贡献榜单里面的人，很多都不是 Google 的，所以即使将来你说的 Google 不支持了，那么照样可以运行下去，就像当初 Unix 在 bell 实验室一样，会有人发扬光大。其次，现在 golang 本身就是故意对 Google 避嫌，任何可见的官网文档、博客都没有出现 google 字眼，你再去对比 Google 的正式儿子：dark 官网，人力投入、资源投入都是和 golang 不是一个等量级的，所以大家不用担心这一点。

#16 楼 @luikore #19 楼 @gaicitadie rust 好的话，mozilla 也不会用 Go 来开发他们的日志处理系统：https://blog.mozilla.org/services/2013/04/30/introducing-heka/

#47 楼 @huacnlee 不是吧，我记得看过 rob 讲的一个演讲，他讲了 Go 如何产生的过程，当初设计的理念是 C++ 编译实在太慢了，而且各种依赖，所以想设计一个简单的语言，C 表达能力不行，而且随着硬件的发展，多核分布式环境的变化，很多语言都是迂回的去利用多核和分布式，所以设计了 Go 语言

我怎么突然感觉一说起 Go 来，很多支持者都特别激进呢！

对于 Go 的未来，还真是未知数，但这不妨碍对 Go 有兴趣的人刨根问底的学习。不论怎么样，我相信能学到的东西肯定一大把。我最不喜欢的就是因为 XXX 火，赚钱多就去学，就像考大学报考专业一样，很多人都是冲着 XXX 专业好，XXX 专业挣钱多而报考。

#50 楼 @fengkuok 给我的感觉是 ruby 社区里面有些人特别激动，思想很封闭，不愿意接收新东西的感觉。其实大家都可以放开心态，多交流多学习才是正道。

ruby 的语法很好。性能问题不是问题，因为硬件在发展。

以后会有写起来更简略的语言出现的。比 ruby 更简便。科技以人为本嘛。

5 年前，跑 ruby 真的很卡。电脑又贵。没办法，当时只能 python。

#48 楼 @astaxie Rust 还没发布正式版。而且 Rust 的目标是写浏览器，Mozilla 正在写 Servo。

而 Go 的目标是 System Programming，Go 已经发布了。

#51 楼 @astaxie 程序员圈子里语言之争从来就没有消失过，不算什么坏事。

#53 楼 @bhuztez 搞个编程语言，就为了写浏览器，目标也太小了

#51 楼 @astaxie 我也觉得，他们像死忠，不知道为什么

#55 楼 @search 没有多少语言适合做浏览器引擎的

#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 的表达能力还弱 -_-.

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

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

#58 楼 @luikore 你好像很了解 C 和 C++ 似的，至少我们项目组里面使用 C++ 编译时间慢的跟一坨屎一样，C++ 解析的语法太多这是无可争议的问题，Google 为了解决的问题是：

• Build 速度缓慢
• 失控的依赖关系
• 每个程序员使用同一门语言的不同子集
• 程序难以理解（代码难以阅读，文档不全面等待）
• 很多重复性的劳动
• 更新的代价大
• 版本偏斜（version skew）
• 难以编写自动化工具
• 语言交叉 Build（cross-language build）产生的问题

没有 macro 的 Go, 很多情况比 C 的表达能力还弱，说的是什么啊？Go 的表达能力强不强用的人都知道啊。你说的来 C 比 Go 的表达能力强大了很多。纯扯淡，上代码就说明一切。

#59 楼 @luikore Rust2006 年就开始搞了，Go2007 年开始搞的，谁新谁旧一眼就知。和干爹根本没有任何关系，定位完全不一样。Go 里面很多 20 年前的旧东西，那还四五十年前的 C 和汇编写的呢，那还用了 1978 年的理论 CSP。

ruby 作为一门解释性语言已经定性了，加入新东西也是在语法层面，无法根本的说明任何问题，就如 rob 所言都是在迂回的去解决一些问题，由多核处理器、系统的网络化、大规模计算机集群和 Web 编程模型带来的编程问题都是以迂回的方式而不是迎头而上的方式解决的。

#59 楼 @luikore 看看 Go 受影响的各种语言系

#16 楼 @luikore 如果真心要比较语言和语言之间的差异，先从起源或者说设计目的讲起； 从语言设计出来后，首先要解决的问题来分析会比较容易避免口水战。至少，在这点上 go 的目标很明确（go 官方对于 gui 开发的态度就是暂时不支持？）。rust 让人感觉并不清晰，没有银弹，但 rust 似乎想当银弹？

#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 代码时，确实遇到过没有泛型不方便的地方，说实话我也非常希望看到这个东西。

#64 楼 @luikore 首先目前的测试结果都表明 Go 和 C 的性能差距在 10% 之内，我觉得从易用性上来说，已经足以替代用 C 写的代码了。你给我解释了那么长的编译器优化，你是想说明什么问题呢？你是想说明 ruby 运行的比 Go 快吗？

其次 Go 的目标也不是把 C 给替换了，我想以后 C 可能就是高级汇编，Go 就是基于 C 之上的一层系统语言，用来做分布式、多核编程。

最后你看看最近 Go1.1 Go1.2 里面的改进都是非常重大的，按照这样的发展速度，我觉得 Go1.4 左右绝对可以实现强大的 GC

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

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

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

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

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

#67 楼 @luikore 2006 年开始的 rust，2007 年提出的 go，你可以去看各种资料啊，而且按照 rust 的发展进程，我想两三年之后才会发布正式版吧。

ruby 的理解是错误的？动态类型的语言就决定了他的特性啊

#68 楼 @luikore 我是本机的 gcc，我那个数据是另一位兄弟测试的，都是基于最新版本的 gcc，我昨天还咨询了为什么启用-O2，他说了-O3 在有些情况下比-O2 还差，你可以自己拿过去测试，测试的博客在这里，我昨天也告诉过你地址：http://my.oschina.net/chai2010/blog/130859

就你测试的那些你可以用最新版本再测试测试

#68 楼 @luikore 就你测试的那个例子就说明 cruby 比 Go 快了，搞笑啊，看看人家专业机构测试的：http://www.techempower.com/benchmarks/#section=data-r6

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

#72 楼 @luikore 晚安，明天再和你讨论

#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 到现在也不见有多少关注 (也没有发布正式版)。

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

#71 楼 @astaxie 请指教啊，我看了下你给的网站在 Github 里的代码，https://github.com/TechEmpower/FrameworkBenchmarks， 里面的 Go 代码（我不是很懂 Go，说错了 Sorry）。我目测数据库访问是一个裸的 MySQL 驱动，用的是 SQL 语句 + PrepareStatement，Http 方面是net/http，貌似是一个内置的 Http 包，里面用的handleFunc和ListenAndServe我 Google 了一下，好像是说是类似异步的方式处理请求的。 帖子 1 帖子 2。

但是对应 Ruby 的框架的测试，我看到了 2 个，一个是 Sinatra，一个是 Rails，这 2 个本身不是异步框架，里面用的也是 ActiveRecord，是一个 ORM 框架。

当然我不是要证明 Ruby 快，我知道 Ruby 不快。但是从这测试的例子看起来，也不是在同一个平面去比较的。

学到不少东西，真好：）

你们继续啊，别停

#76 楼 @kenshin54

这个比较本来就是来搞笑的，很多东西都不在一个层面上的

#76 楼 @kenshin54 TechEmpower 的测试可能是在自然状态（没有特殊优化，使用默认方案）下的测试吧，其中很多框架都没有使用异步的

虽然知道不太可能，但是还是希望能把 Android 用 Go 来编写。。。

Java 真的太蛋疼了

go 明显是用来做系统语言的，语法就像一个 c 的方言。从我角度来看，无法取代 c，也许可以玩一玩。 和 ruby 就没什么交集了，一个是看重开发效率，一个是看重执行效率，完全是两条路上的东西。

新学一门语言没什么坏处，学学 go 挺好的。 至于学了有没有什么用，我的感受是学了越多越发觉用处不大，如果你想设计一门语言，也许会拓宽思路，但是做应用级别的开发，用处不大。

#81 楼 @skandhas 嗯我自己也学习到很多东西，这样的基于语言层面的讨论，我觉得相互学习，也让我更加深入的理解 ruby，也让大家了解一下 Go

#76 楼 @kenshin54 #79 楼 @jjx 他们这个测试是基于框架本身的对比，如果你觉得有更好的框架，例如基于异步的 ruby 框架，你可以去递交代码，那是 github 开源的，加入测试，让更多的人了解。

#81 楼 @skandhas 其实，我并没有提及 ruby 社区，我的意思是这里有些人。但我没有说他们怎么样，只是有些好奇而已。

#86 楼 @astaxie

本身没有意义的比较，你花在这方面有什么意思。有些框架很重，有些框架很轻，有些直接用 c , 有些只能用同步，有些只能用异步，有些要借助特定的比方说 uwsgi, 特定的进程数才能跑的好。比方说 python bjoern ab 可以接近 nodejs 的性能，你不能说 python 比 v8 一样快，完全没有意义

#83 楼 @rasefon 我也认为取代 C 是不大可能的，但是我认为以后 C 可能就是高级汇编，但是 Go 可以替代我们网络编程的功能

楼主这样想，只能说明楼主根本不了解 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 类似的并发思路).

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

#80 楼 @slene #89 楼 @astaxie

所以这个不能拿来做 CRuby 和 Go 以及任何其他语言比较的基准。

去他的，扯淡！学个 ruby，学个 python，学个 golang，学个 scala......很花你时间吗？很影响你一辈子的前途与钱途吗？既然抱怨、吐槽的时间都有，何愁没学习的时间？学习一个新工具，不会因此把算法基础、架构设计思想、项目经验...等等丢掉！如果你是个老兵，更有理由去辨识、发掘新工具的优缺点，适合或不适合的应用范畴等，而不是纯扯淡；如果你是新手，更有理由去做的学好基础，以一门语言工具为引子，在不断学习该语言工具的过程中逐渐发掘与掌握软件开发的各种基础。而不是纠结于工具之争中。当然，新手为了饭碗问题的话，那更有理由首先去择一门热门工业语言工具入手。

不管 golang 国内热还是不热，你说的他干爹 Google 还真没专门为他干多少事。再者 golang 开源项目，你说的 Google 放弃后码农挑灯夜读就打水漂了，这逻辑太扯淡。无数开源项目摆在那，有兴趣的有需求的自然会投身进去，没兴趣的没需求的同样会置之不理，但是它们就在那！别奢想银弹，心态问题。

#63 楼 @astaxie Rust 很清晰啊，就是把各种成熟的理论上已经研究的很清楚的语言特性都加进来试试，对写浏览器有帮助就留下，没帮助就去掉。Go 才想当银弹好不好

#64 楼 @luikore

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

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

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

Go 编译快的原因：

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

玩 C++ 有没有去编译过 linux 下的 qt 和 KDE ? 那得要排放多少碳 (co2) 呀。

#95 楼 @bhuztez

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

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

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

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

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

插一句，go 学习一下感觉代价还好，能处理解决现在所需的编程问题的话，个人还是可以接受的~ 感谢各位，今天我学习了 :-)

#89 楼 @astaxie c 不会是高级汇编。。。 我觉得 c 的语法上和现代语言没什么区别，比如所谓 oo，或者函数式编程，都可以用库的方式解决。 c 的优势很现实，os，tcp/ip 这类基础设施，都是由 c 写成的，外加可以完美结合 asm，它作为系统级语言地位无法被动摇。我甚至觉得 go 是 c 的一种 dsl。

#102 楼 @rasefon 嗯，我只是用这个比喻目前 C 和汇编的位置，将来就是 Go 和 C 的位置

#52 楼 @sevk 性能当然是问题了。你做过运维么，如果 go 的性能是 ruby 的 20 倍，那就少 20 倍的机器，600 台机器和 30 台机器管理起来不是一回事。

还有 twitter 之前不是都是 ror 么，后来切到 JVM 平台，也不宕机了，腰不酸了，腿不疼了，一口气上五楼了。

#64 楼 @luikore 说解释运行比编译运行效率高，那也是只是说极限而已（而且是理论上的极限），jvm 的 JIT 已经做了这么多年了，也没见真正达到 C 语言的水平。JIT 编译器本身需要在编译速度和编译质量之间很好的权衡，未必就能做出最好的优化。不知道 ruby 的 VM 何时才能做到 JVM 水平。

#96 楼 @chai2010

一个 C++ 版本的 helloworld, VC2010 展开后是 70000 行. 这个 7 万行是汇编的行数？ 真的？求截图

#104 楼 @fanngyuan 你是说每台机器的 CPU 或内存都是 满负荷运转的？那就是硬件太落后了，赛扬处理器。

#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. 在解决二义问题时浪费了编译时间没有？

#108 楼 @sevk 你觉得 twitter 这么穷么

#110 楼 @fanngyuan twitter 是 5 年前的，确实慢，硬件问题。

#111 楼 @sevk 那您搞个五年之后的硬件把

#99 楼 @luikore

1. c++ 写了个 hello world 展开确实会有 70000 行，但是 Go 展开的话也不少，这个不能说明问题，C++ 编译主要慢在上下文的解析，一旦引入模板就更悲剧了。

2. Go 减少包的依赖这个无可争议的比 C++ 牛逼很多，没有必要的 pkg 确实不需要引入，而 C++ 就是一杆子打死引入很多无谓的包，而不是按需索取，当然 C++ 也可以控制的很精细，但是这个代价非常大。

3. 这一点 Go 的设计明显出于工程的考虑，没有使用的变量报错这是从编写代码阶段就防止隐藏的 bug，这种 unused 的就必须报错

4. Go 的二义可以精确的设计到这个，https://docs.google.com/document/d/1bMwCey-gmqZVTpRax-ESeVuZGmjwbocYs1iHplK-cjo/pub 你觉得 Go 的语法优化的不够吗？

终上所述，Go 是一门让你降低心智，让程序员少犯错的工程性语言

做 Web 开发的，跟 Go 关系不大。不过 Go 的语法还不错，编译出来的也是 a.out，很有 linux 下写 c 的感觉。

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

#115 楼 @hooluupog

C 才不是最快的呢。C++ Fortran Ada Haskell 都有比 C 快的单项。

说 C 快的根本就不懂 C。

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=fannkuchredux&lang=all&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=fasta&lang=all&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=mandelbrot&lang=all&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=knucleotide&lang=all&data=u64q

#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 根本就没花多少心思在设计语法上。

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

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

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

#117 楼 @luikore

1. 首先我就说了 7w 行无关紧要，但是 C++ 编译慢是必然的，你无需争辩
2. 你花了几分钟就解决了 Google 都无法解决的 include 依赖问题，算你狠
3. 一个是 warning，一个是编译不通过，这就是不同层面的问题了，很多人吐槽这一点，但是我是人为从工程的角度来说，这是杜绝了隐藏 bug
4. 你根本就不了解 Go，Go 的类型写后面不是为了 parsing，看看最近许式伟在微博的解释吧，Go 根本没化心思在设计语法上，说出这样的话只能让我觉得你有点自大了，也不看看 Go 的发明者都是谁，说他们不懂编译，二义性之类的就像你说 Linus Torvalds 不懂操作系统一样啊。

最后使用 Go 能够让程序员少犯很多错误，这个就让我们可以化更多的时间在其他上面

#68 楼 @luikore 欢迎提供 ruby 的测试代码，还有 Go 的测试代码，我想自己测试一下，还有 Go 的测试，无需 ioutil 的包读取内容

照着 TechEmpower 写了个 Benchmark，比其他删掉了，就做了个查询的测试，结果取的是平均值接近的整数。

https://gist.github.com/kenshin54/6724497

ab -n 1000 -c 10 http://localhost:3001/
ab -n 1000 -c 10 http://localhost:8080/

Average:

Go

Requests per second: 6000 [#/sec] (mean)

Ruby

Requests per second: 4000 [#/sec] (mean)

Go 是快，但是 Ruby 也没慢太多。

Benchmark 一直都是很无聊的。。。。

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

头像配标题，真是一绝！

#122 楼 @kenshin54 拿 ruby 和 Go 对比性能，我只能说别测试了，反而会很难堪，还有你并发打得少一点，那 Go 和 ruby 的性能还能很接近呢。

go-china.com

你们都上当了！ 看 lz 的头像，这是一盘不小的棋啊！

#125 楼 @astaxie 之前是你扔出来说'专业'的测试机构，跟你说他测法不对，你说自己写，现在写了，结果也给了，你又说别测试了。有意思么？你拿 Go 和 C 比语言表达能力，和 Ruby 比性能，也真是会比啊。并发加到 100 也差不多。

#128 楼 @kenshin54 我是觉得拿 Go 和 ruby 比性能没必要，只会让 ruby 自取其辱，你 ab -n 100000 -c 10000 测试测试

#129 楼 @astaxie 2 个通通挂掉

#130 楼 @kenshin54 那说明你的机器不行嘛，你慢慢加并发量试试看吧，这样也能说明稳定性、性能各方面的对比。还有当并发大了之后我感觉 ab 不行，你可以试试 wrk 这个工具，我觉得不错

看来还是 java 好啊

这种测试确实没啥意义，2 个崩是掉数据库连接池不够。整个 Web 应用受影响的面太多了，数据库，缓存，集群，异步处理，关测试语言性能没意思。所以我前面也说了，这是很无聊的测试，跟 helloworld 没区别。

瓶颈在语言层面我不能说没有，但前面有太多层 stack 要经过，大部分瓶颈都会在前面。

#103 楼 @astaxie 不太同意，汇编和 c 的区别就像汽车和自行车，go 和 c 的区别只是牌子不同的汽车而已。

学一下也好，重点是了解原理，这样也许自己就能开发出一种语言来。

照楼主的说法，Ruby China 赶紧散伙了吧，哪天松本行弘走路上被车撞了，各位在 Ruby 上的投资就都打水漂了。Go 是个开源项目，只要社区还有人支持它，跟 Google 放弃不放弃有什么关系么？

最近在看 go，感觉还好，速度 ruby 根本没法比的，这个谁都知道，不过用习惯了 ruby，用 go 很不习惯的感觉，没那么方便，速度开发还是 ruby，也用了@astaxie 的 beego, 感觉挺不错的，学学不吃亏，最爽的就是把项目打个包往服务器上一丢就可以了

我比较看好 nodejs~~

go 相比与 c/c++ 来说，确实在工程上改善很多。

1）解决循环依赖 2）error 返回值，再也不用在基础库中打印错误日志了 3）简单的字符串处理库 4）go fmt，保持团队统一的编码格式 5）内置的 slice, map，STL 是够蛋疼的 6）interface，帮助我们 c/c++ 程序员设计更优雅的软件 7）channel，更清晰的编写多线程程序

根据我的实际经验，用 go 替代 c/c++，至少可以将代码量降到 50% 一下

我们测试的 go 进程单机跑到了 5.4w rps

@kenshin54 你的 benchmark 太弱了

#141 楼 @kula 这数据碉堡了，比我这 i7 2600k 的破机子 nginx 静态文件访问都快了，土豪我们做朋友好不好

七天七语言表示学点新语言没什么成本

#143 楼 @quakewang 关键 Go 现在能用来干嘛？服务端它目前一展身手的场合主要适合用 erlang 之类的，但 erlang 用的也不多。

#144 楼 @swachian Erlang 推广策略有问题，问题很严重很严重

#145 楼 @bhuztez 我是觉得语言是拿来用的，不说明应用场合的情况下，是否值得学习的必要性根本无从谈起。像 Erlang 是做高并发应用的，似乎是跟着几个 NoSQL 一起火的，之前冷了很多年；Ruby 是借着 Rails 在 Web 开发火的，之前窝在日本无人知道，但出身也是 linux 的脚本语言；python 是写算法、做运维脚本开始流行的。

Go 究竟适合用来开发什么类型的软件？目前看下来，这东西肯定不是脚本类语言。

#105 楼 @fanngyuan 又黑 ROR,

#146 楼 @swachian 说得不错，合适的才是最好的。@fanngyuan 说的 twitter 从 ROR 换 JVM, 有几个公司会有这种问题？

#146 楼 @swachian Erlang 推广最大的失败就是让人觉得它只适合高并发...

Go 究竟适合用来开发什么类型的软件？目前看下来，这东西肯定不是脚本类语言。

Go 的目标实际上和 Ada 差别不大。可惜 Ada 太早了，晚个几十年，加个 Type Inference 早就把 Go 轰成渣了

楼主的理由都不是理由

#149 楼 @bhuztez Ada 听说把 欧洲空间局阿丽亚娜 5 型运载火箭弄爆是什么情况？

我也歪楼下。。。。

Bill 是坏小子，又再黑谷歌了，说 Dart 可能更切合些？

每次都是不知觉励 哎。。。对 C 写东西，还从没又过。。。哎。。。

bill 黑 google，嗯。正常

#20 楼 @Saito 现在一个 tcp 链接要用 std::rt::io::net::tcp::TcpStream，美感在哪里？

#155 楼 @reus 对呀：

use std::option::Option;

fn call_me_maybe(x: int) -> Option<int> {

代码写成这样还摆得出来。

--- 打字太曲折了！

#156 楼 @gihnius 怎样写比较好呢？

忘记哪位大牛说过，现在的语言性能都不会有太大提升，所以我感觉什么编的快 就用什么比较好！

我觉得就算 google 抛弃它，也还是会有很多爱好者继续研究的！

作为语言学习很好，不用作生产很好，很好~~~

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

招人啊，我们在用 Go 做https://qortex.cn，还在公测阶段，收费前入住的会一直免费，你们感受下（不好意思，发广告发习惯了...)

#52 楼 @sevk 不能同意太多。硬件的发展，会淘汰一些语言。

#162 楼 @jinleileiking 硬件只是影响了语言的 执行效率 而已。没有影响语言的其他指标 (比如体积大小，嵌入式方便否，设计初衷，适用领域等)

#64 楼 @luikore https://docs.google.com/document/d/1szwabPJJc4J-igUZU4ZKprOrNRNJug2JPD8OYi3i1K0/edit#heading=h.ywtmh4qacfis New SSA Backend for the Go Compiler 要换到 SSA 后端了

#165 楼 @reus 挺好的方向，实现了么？

#166 楼 @luikore 刚开始 https://go-review.googlesource.com/#/c/6681/

吵呀吵呀吵呀吵，吵到一个好基友！

#53 楼 @bhuztez 说 rust 的目标就是为了写浏览器也是醉了。这么说，那些能自举的语言都只是为了写个编译器而已了。。。

说得好像 Go 在国外不火一样。起码感觉有在 Web 领域取代 Python 的潜力。 感觉 Ruby 才越来越小众了

一年前在使用 Golang 也就是跟着国内流行的热风，现在回头看 当时并不理智

赶紧 sibi，Go 1.7 准备上 SSA 后端了

#148 楼 @jun1st

jun1st · #148 · 2 年前
#146 楼 @swachian 说得不错，合适的才是最好的。@fanngyuan 说的 twitter 从 ROR 换 JVM, 有几个公司会有这种问题？

但凡压测的时候需要达到单机一千 QPS 的，都会有这个问题。

体量不够，就不会有这个问题。

典型的就是微博，电商。

目前的主流配置，Laravel 这个丢脸的框架只能达到 250-270，手工优化的 PHP 可以到一万，不过也分情况。 Java 看业务，一般 500 到 1000 都可以。

至于 ROR……

没具体数据，找到了这个。 http://www.isrubyfastyet.com/ 120 不到？

（以前有博客提到，ruby 给人的印象慢，是因为 ror 慢，难道是真哒？twitter 不再出现鲸鱼了，是因为从 ruby 迁移到 java，难道是真哒？）

个人觉得 Go 的简洁及并发性挺不错的，如果怕 Google 放弃也不太妥当，毕竟是开源项目了。Docker 这么大的项目都出来了，一旦有了严肃的商业项目来应用某个语言，那么这个语言就有了很强的生存力，你 Google 不弄了，Docker 社区的人也得弄下去。

所以我个人不赞赏这样有失偏颇的结论，同时也鼓励大家多学点东西，没必要非此即彼，所以我并不否定 Go，但同时我也会建议去了解了解其他新语言，比如 Rust，与其在这里斗嘴角，不如写点 code，或者做点技术分享，我是 Rust China 社区 http://rust-lang-cn.org/ 的创办者，我也曾经用 Go 写过一个公司的管理系统，都用用，都写写，你自然会知道自己喜欢什么，但也不要把自己的看法强加在别人身上。

这就是我的看法。

马上 2017 了

这么多赞？ 可是 rust 定位的是系统编程啊，社区在 web 方面贡献热度很低，很多库更新都很慢。 没有绿色线程，起码我没听说哪个 web 框架用的是绿色线程。 很多基本的库仍然还没有，或者说不成熟。

洛阳铲

2019 了，go 的热度远远超过了 ruby

这帖子的讨论是我在 Ruby China 看到过最热烈的了，简直跟看武侠小说一样，好爽。

现在感觉 Go 虽然称不上漂亮，但是干活还是挺利索。作为中年码农，夫复何求？

2020 年 8 月了，go 依然火热，帖子上不被人看好的在线协作系统在中国也很火热了。13 年到 2020 年，7 年多的时间，不得不说，Google 的想法很多都挺有前瞻性的。

7 年过去 , 楼主改变看法了嘛？

go 语言排名跌到 18 位了 https://www.oschina.net/news/154005/tiobe-index-202108

Go 现在的定位本身就是基础设施层，这个排名也算正常

那么多年过去了。

Go 在云计算平台的基础设施上，Docker、K8S 等方面，确实找到了自己的一片天地。安全人员很喜欢用 Python+Go。 在一些坊的实现上，也大量地被使用着。

Web 领域、应用服务端领域，依然基本没 Go 啥事。

应该说也很不错了，只是和 C/C++, Java, Python, Javascript 的流行度依然相差非常远。而且对上述主流语言的影响或者是指导非常非常的少。