通知_CSGO中文网_易玩网 - 5E对战平台官网
文章信息不存在，或者正在审核中！真的没必要浪费心思在 Go 语言上 · Ruby China
本帖已被设为精华帖！
Go语言好不好，快不快，人性化与否这些不讨论，光说google一概的作风，没必要在Go语言上作知识投资。google推出的新玩意太多了，大多数都是google的人头脑一时发热就搞出来了，头脑一冷静就没下文了。google扔掉的东西太多了，google都没把Go语言当回事，国内却掀起了学Go的热潮。假如有一天google宣布放弃Go语言项目，码农的无数个挑灯夜读就打水漂了
好好玩转Ruby挺好的
这个还是看社区，google是否有能力创建一个社区。sun买mysql的原因就在与mysql后面的社区，用户数太大了。
按照 Slashdot 的风格，这个帖子下面应该有一堆
[citation needed]
其实说到弃坑 M$ 那边的也有不少。。
大约在08年的时候，google出了一套在线协作系统，铺天盖地的媒体公关文，号称要革email的命，互联网的下一代XXX，一时间网上都在求邀请码注册个帐号，朋友也发给我一个邀请码，还发给我一个pdf文档，用来学怎么使用这套系统的。一套需要读文档才能玩的转的系统，注定是要悲剧的，果然没过多长时间，google宣布放弃这个项目了，说是太先进太超前，以至于不被网民接受云云。。。现在我都记不起那个项目的名字了
09年的google wave?
还有一个系统，貌似是类似disqus的那种给网站提供评论服务的，google的公关文说是要革im的命，革qq、oicq的命，后来也没有下文了。经历的次数多了，就对google的这些项目免疫了。要革facebook命的plus项目现在也半死不活。
google是个追求金钱的商业公司，就是再高尚也得追求金钱，并且google的风格是短期带来效益，如果短时间内不能带来效益，google是没有耐心放长线钓大鱼的。这点还不如微软，微软至少对自己的产品支持的周期要长一些，google说扔就扔，没商量。
google对自己产品的态度就像押宝，押对了就继续投入资源(比如android)，押错了就把它扔一边任其自生自灭
好吧,我本来都在 rubylearning 上报了课程了,果断被楼主骂醒
go是个开源项目，就算google不维护了，肯定会有人继续维护
另外，学习go没有坏处吧
我是觉得他确实很有趣才学的
支持楼主，我觉得一个人的精力有限，手上用熟悉一种语言再说，如果真的遇到了这个语言都无法解决的瓶颈，那说明你成功了，你已经有大笔大笔的钱，可以招青年才俊帮你去解决了。
程序员容易陷入技术里面去，如果是自己创业的话，重要的是想法和运营。
在线协作不是整合到 Google Drive 里面了么？
你说的 Wave 已经被人接手了
如果 Google 是一个平庸的公司，也不会去想着革谁的命了。
真的没必要浪费心思在这个topic
盖茨说的对！
就语言本身设计来说
web 开发, 如果一个语言不支持元编程, 没有 map, reduce, each_slice, find ... 等函数, 写复杂业务逻辑就是噩梦...
相似的语言的话,
设计得更好, 相比 Go 的各种优点:
GC 可选, 性能甩 Go 一条街
Ruby-like lambda and do block
除了 let 和 ; 以外都是表达式
模式匹配和无 null
macro - 可以自己搞各种字面量, web 完全是个拼字符串的世界, 没有正则表达式字面量玩个毛
不需要为用不到的语言特性买单
还真不觉得几个大佬是一时头热才做这个项目的
赞同, map reduce filter curry .....
学rust的时候很有ruby的感觉，写起来很舒服很人性化，只是他的爹不如go的爹牛气，从新浪微博一搜竟然还有很多说rust不如go人性化的，这是个拼爹的社会
Go 的代码缺乏美感.
Taste 很重要啊.
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 .
对啊, 这个拼爹社会里人的认识受各种因素影响, 反而失去了对事物本身的判断能力...
Rust 貌似发展很缓慢，社区也不太活跃。各种工具，lib 都很少。现在想在产品环境用，恐怕不行。
Rust和Go怎么能说是相似呢，目标都不一样...
可以无缝使用 C/C++ 的 lib 啊
curly brace 密度上相似...
Rust 目标是 C++
Go 目标是 Ruby Python 或者 C 想做 Web 的...
类C的语法都差不多吧。问题是Rust和Go语义上差别也太大了。
Rust都还没发布正式版呢...
map, reduce, each_slice, find ... 等函数，不是可以自己实现吗，语言核心级别不提供也没关系吧？
动态链接是个bug ...
不需要为用不到的语言特性买单
让人想起了C++
我是从这个角度看的: static suffix-typed C-like with local type inference ... 最初 Go 的目标也是 C++, 不过是服务器端 C++, 后来没吸引到 C++ 程序员就转到动态语言用户群中挖角了
Go的目标是System Programming，Go的目标是要革C在应用开发的命
Rust的目标是写浏览器，Mozilla很保守，就是把已经研究得比较充分的语言特性能拿过来试试，能比C++好一点就可以了。
只要有相关的库，rust开发web未尝不可，会比go舒服的多，至于rust复杂的那部分，开发应用可以无视它，光用它简单的那部分已经比go顺手多了。静态编译语言，竟然能有写ruby的感觉，非常难能可贵
有关系哦, 你看见有几个 Go 的使用者会用这些函数? 不少人实现了发现用起来根本没 Ruby 的一半方便就放弃了回到 for 循环里了
你这帖子也太符合分类了……
Go本来就是一帮C/C++程序员尝试用来代替C/C++的……我认为它已经做到了A better C
但如果你的喷点在于做web开发……我也认为这不是Go适合的领域……就像正常人不会用C写web一样……
至于Rust……语法蛋疼成这样也有人说人性化？我反正无法接受……
Rust语法都没最终确定呢
搞得好像Rust不用for一样的
至少不是碰到个问题就三重 for 拍上去... 好吧 Go 的目标是取代 C 在 Web 开发中的地位...
我没说Web...
我也喜欢rust多过golang，不过也不觉得golang有多不堪。包、测试、调优这些机制，用过之后都觉得很贴心。rust有些机制也是向golang学习的，比如rust命令、信号的处理之类。
如果我没有学过golang，估计也体会不到rust的妙处，而只会把它看成另一个C++。当然了解rust之后再反观C++，也对它有了更多理解，反而觉得以前人云亦云的态度不好。
google可以怎样放弃golang项目呢？本来就不需要多少资源就能养活的东西，和那些关闭了的服务完全不一样。最不济也就是变回业余项目，bug修复变慢，特性不再加，如此而已。以现在的稳定程序，google对golang如何，根本不影响使用。
品味高低、优雅与否，这些只会是学习新事物的障碍。我之前用得最多的是python，对于一大堆{}的语言也是提不起兴趣的。但现在觉得，这么精彩的新世界，自己主动闭目塞听，实在太愚蠢了。
这种讨论，就像争论长矛和大刀哪个更厉害一样。
不会有结论的。
我表示包挺好, 测试没有 assert 不贴心, 调优是必须的...
尤其是pprof的http接口，太良心了
就目前来说, go 还是不错的.
ruby 虽好, 但为什么都差不多 20 年了, 人们才发现它的好. 以后的事还很难说的.
关于 Google 对 golang 的支持，
前段时间听了个 podcast， Rob Pike 说其实 go 一直跟 G 公司关系分得很清，比如 golang 网站上都没出现过 google 字样 （有心跟 Angularjs 官网对比一下），他到希望 G 公司能多给点支持。不过， 他又说，现在就算没有 google 支持项目仍然可以发展下去，而且 google 内部目前用的也不多。
最八卦的一点是，golang 的 Windows 移植部分主力是中国程序员干的
Podcast 在
我记得 Go 当初是说应对 Web 而生的
一群人瞎喷，首先Go是开源项目，目前虽说主力开发的人还是Google的为主，但是你去看看贡献榜单里面的人，很多都不是Google的，所以即使将来你说的Google不支持了，那么照样可以运行下去，就像当初Unix在bell实验室一样，会有人发扬光大。其次，现在golang本身就是故意对Google避嫌，任何可见的官网文档、博客都没有出现google字眼，你再去对比Google的正式儿子：dark官网，人力投入、资源投入都是和golang不是一个等量级的，所以大家不用担心这一点。
rust好的话，mozilla也不会用Go来开发他们的日志处理系统：
不是吧，我记得看过rob讲的一个演讲，他讲了Go如何产生的过程，当初设计的理念是C++编译实在太慢了，而且各种依赖，所以想设计一个简单的语言，C表达能力不行，而且随着硬件的发展，多核分布式环境的变化，很多语言都是迂回的去利用多核和分布式，所以设计了Go语言
我怎么突然感觉一说起Go来，很多支持者都特别激进呢！
对于Go的未来，还真是未知数，但这不妨碍对Go有兴趣的人刨根问底的学习。不论怎么样，我相信能学到的东西肯定一大把。我最不喜欢的就是因为XXX火，赚钱多就去学，就像考大学报考专业一样，很多人都是冲着XXX专业好，XXX专业挣钱多而报考。
给我的感觉是ruby社区里面有些人特别激动，思想很封闭，不愿意接收新东西的感觉。其实大家都可以放开心态，多交流多学习才是正道。
ruby的语法很好。 性能问题不是问题，因为硬件在发展。
以后会有写起来更简略的语言出现的。比ruby更简便。科技以人为本嘛。
5年前，跑ruby真的很卡。电脑又贵。没办法，当时只能python。
Rust还没发布正式版。而且Rust的目标是写浏览器，Mozilla正在写Servo。
而Go的目标是System Programming，Go已经发布了。
程序员圈子里语言之争从来就没有消失过，不算什么坏事。
搞个编程语言，就为了写浏览器，目标也太小了
他们像死忠， 不知道为什么
没有多少语言适合做浏览器引擎的
不了解 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 的表达能力还弱 -_-.
Go 里很多都是 20 年前 Inferno OS 的旧东西... 这几年 Ruby 里添加的新东西也有很多哦, 建议你了解一下. Rust 作为比 Go 更新更好的语言, 受到的关注却有点太少了, 还不是没有 google 干爹的缘故.
如果 Go 相关的新闻里都没有 "Google" 字样, 首先记者发这个消息的动力就会少一半, 然后读者关注度更加大打折扣... 所以就算作者说和 google 没关系, 市场受到 google 影响是显然的.
你好像很了解C和C++似的，至少我们项目组里面使用C++编译时间慢的跟一坨屎一样，C++解析的语法太多这是无可争议的问题，Google为了解决的问题是：
Build速度缓慢
失控的依赖关系
每个程序员使用同一门语言的不同子集
程序难以理解（代码难以阅读，文档不全面等待）
很多重复性的劳动
更新的代价大
版本偏斜（version skew）
难以编写自动化工具
语言交叉Build（cross-language build）产生的问题
没有 macro 的 Go, 很多情况比 C 的表达能力还弱，说的是什么啊？Go的表达能力强不强用的人都知道啊。你说的来C比Go的表达能力强大了很多。纯扯淡，上代码就说明一切。
Rust2006年就开始搞了，Go2007年开始搞的，谁新谁旧一眼就知。和干爹根本没有任何关系，定位完全不一样。Go里面很多20年前的旧东西，那还四五十年前的C和汇编写的呢，那还用了1978年的理论CSP。
ruby作为一门解释性语言已经定性了，加入新东西也是在语法层面，无法根本的说明任何问题，就如rob所言都是在迂回的去解决一些问题，由多核处理器、系统的网络化、大规模计算机集群和Web编程模型带来的编程问题都是以迂回的方式而不是迎头而上的方式解决的。
看看Go受影响的各种语言系
如果真心要比较语言和语言之间的差异，先从起源或者说设计目的讲起；
从语言设计出来后，首先要解决的问题来分析会比较容易避免口水战。至少，在这点上 go 的目标很明确（go 官方对于 gui开发的态度就是暂时不支持？）。rust 让人感觉并不清晰，没有银弹，但 rust
似乎想当银弹？
别激动... 理论上 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 的编译器设计就已经给自己划定了极限...
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代码时，确实遇到过没有泛型不方便的地方，说实话我也非常希望看到这个东西。
首先目前的测试结果都表明Go和C的性能差距在10%之内，我觉得从易用性上来说，已经足以替代用C写的代码了。你给我解释了那么长的编译器优化，你是想说明什么问题呢？你是想说明ruby运行的比Go快吗？
其次Go的目标也不是把C给替换了，我想以后C可能就是高级汇编，Go就是基于C之上的一层系统语言，用来做分布式、多核编程。
最后你看看最近Go1.1 Go1.2里面的改进都是非常重大的，按照这样的发展速度，我觉得Go1.4左右绝对可以实现强大的GC
你对 ruby 的说法是错的. 说明你完全不了解也不想去了解 ruby.
2006 版 rust 对应的应该是 limbo 而不是 go 的 2007 版...
program that writes program 才是语言发展的王道, 不管语法还是编译器都是这样进化的, 没有元编程能力显然是倒退...
我很早就回过了, 再指明白一点吧: 因为你的测试用了四年前的 GCC, 而且优化选项开得比较低
2006年开始的rust，2007年提出的go，你可以去看各种资料啊，而且按照rust的发展进程，我想两三年之后才会发布正式版吧。
ruby的理解是错误的？动态类型的语言就决定了他的特性啊
我是本机的gcc，我那个数据是另一位兄弟测试的，都是基于最新版本的gcc，我昨天还咨询了为什么启用-O2，他说了-O3在有些情况下比-O2还差，你可以自己拿过去测试，测试的博客在这里，我昨天也告诉过你地址:
就你测试的那些你可以用最新版本再测试测试
就你测试的那个例子就说明cruby比Go快了，搞笑啊，看看人家专业机构测试的：
撸撸睡了... 晚安
晚安，明天再和你讨论
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到现在也不见有多少关注(也没有发布正式版)。
Go的源代码tools目录下有个SSA就是专门给编译器用的，所以说Go的“编译器设计就已经给自己划定了极限”似乎不妥。另外别忘了还有gccgo和llgo(llvm后端的Go编译器，有人在开发这个)。
请指教啊，我看了下你给的网站在Github里的代码，，
里面的 Go 代码（我不是很懂 Go ，说错了 Sorry）。我目测数据库访问是一个裸的 MySQL 驱动，用的是 SQL 语句+ PrepareStatement ，Http 方面是net/http，貌似是一个内置的 Http 包，里面用的handleFunc和ListenAndServe我 Google 了一下，好像是说是类似异步的方式处理请求的。
但是对应 Ruby 的框架的测试，我看到了2个，一个是 Sinatra，一个是 Rails，这2个本身不是异步框架，里面用的也是 ActiveRecord，是一个 ORM 框架。
当然我不是要证明 Ruby 快，我知道 Ruby 不快。但是从这测试的例子看起来，也不是在同一个平面去比较的。
学到不少东西，真好：）
你们继续啊，别停
这个比较本来就是来搞笑的, 很多东西都不在一个层面上的
TechEmpower 的测试可能是在自然状态（没有特殊优化，使用默认方案）下的测试吧，其中很多框架都没有使用异步的
有可能是对 Ruby 社区的特点了解的少，所以才会使两位产生这样的误解。 其实 Ruby 社区(也包括国外的) 是我接触到的，包容性及接纳新事物都是相当不错的社区。比如对 Node， Erlang，Clojure， Haskell， LISP， Go 都有很好的讨论，这个社区也从不盲目拒绝新事物，也很清楚各个语言是协作而不是对立的关系。
社区的一个特点是喜欢就问题直接展开讨论，基本不会拐弯抹角。而且是全带干货的讨论(这一点很重要)。比如这个帖子，从大家的讨论中，我就学习到很多，相信其他观众也是。
接触 Ruby 社区时间长了，就会喜欢上社区的 Style. 而且是双方都受益。 热烈欢迎讨论！(用平常心讨论就好)
虽然知道不太可能，但是还是希望能把Android用Go来编写。。。
Java真的太蛋疼了
go明显是用来做系统语言的，语法就像一个c的方言。从我角度来看，无法取代c，也许可以玩一玩。
和ruby就没什么交集了，一个是看重开发效率，一个是看重执行效率，完全是两条路上的东西。
新学一门语言没什么坏处，学学go挺好的。
至于学了有没有什么用，我的感受是学了越多越发觉用处不大，如果你想设计一门语言，也许会拓宽思路，但是做应用级别的开发，用处不大。
嗯我自己也学习到很多东西，这样的基于语言层面的讨论，我觉得相互学习，也让我更加深入的理解ruby，也让大家了解一下Go
他们这个测试是基于框架本身的对比，如果你觉得有更好的框架，例如基于异步的ruby框架，你可以去递交代码，那是github开源的，加入测试，让更多的人了解。
其实，我并没有提及 ruby社区, 我的意思是这里有些人. 但我没有说他们怎么样, 只是有些好奇而已.
本身没有意义的比较,你花在这方面有什么意思. 有些框架很重,有些框架很轻,有些直接用c , 有些只能用同步,有些只能用异步, 有些要借助特定的比方说uwsgi, 特定的进程数才能跑的好. 比方说 python
bjoern ab可以接近nodejs的性能, 你不能说python比v8 一样快, 完全没有意义
我也认为取代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他们还会真的失业吗?
C语言之父Dennis M. Ritchie也是Limbo的粉丝, 具体看他写的Limbo语言规范:
Limbo是语言的亲爹, 但是Go的并发背景却是有久远的历史的.
最早从UNIX的管道(其实在UNIX之前就有类似的思想), 到CSP的理论,
到Newsqueak(Rob Pike 1989), 到Alef(Phil Winterbottom 1993),
然后就是Limbo和Go. 其中, 只有Alef和Go是C-like的, 但是Alef只有Plan9短暂支持.
我觉得Go语言是这类语言的真正回归(我比较喜欢Go中和Alef类似的并发思路).
不要混淆编程语言和网络服务的概念. 使用Go语言又不需要Google的服务器支持.
代码就在那里, 难道Google关闭golang.org网站就会导致语言消失吗?
所以这个不能拿来做 CRuby 和 Go 以及任何其他语言比较的基准。
去他的，扯淡！学个ruby，学个python，学个golang，学个scala......很花你时间吗？很影响你一辈子的前途与钱途吗？既然抱怨、吐槽的时间都有，何愁没学习的时间？学习一个新工具，不会因此把算法基础、架构设计思想、项目经验...等等丢掉！如果你是个老兵，更有理由去辨识、发掘新工具的优缺点，适合或不适合的应用范畴等，而不是纯扯淡；如果你是新手，更有理由去做的学好基础，以一门语言工具为引子，在不断学习该语言工具的过程中逐渐发掘与掌握软件开发的各种基础。而不是纠结于工具之争中。当然，新手为了饭碗问题的话，那更有理由首先去择一门热门工业语言工具入手。
不管golang国内热还是不热，你说的他干爹Google还真没专门为他干多少事。再者golang开源项目，你说的Google放弃后码农挑灯夜读就打水漂了，这逻辑太扯淡。无数开源项目摆在那，有兴趣的有需求的自然会投身进去，没兴趣的没需求的同样会置之不理，但是它们就在那！别奢想银弹，心态问题。
Rust很清晰啊，就是把各种成熟的理论上已经研究的很清楚的语言特性都加进来试试，对写浏览器有帮助就留下，没帮助就去掉。Go才想当银弹好不好
搞编译器的朋友表示动态语言理论极限会比静态语言快...
动态语言和静态语言有区别？
C++编译慢的原因:
一个C++版本的helloworld, VC2010展开后是70000行.
怎么能不慢?
Go编译快的原因:
1. import代替include, 防止了头文件展开导致的代码指数增长.
2. Go禁止import未使用的pkg, 减少了pkg的依赖
3. Go禁止定义未使用的变量, 减少了类型的依赖(也就减少了pkg的依赖)
4. Go语法规则便于编译器实现和优化(且少了很多歧义)
C++ 有没有去编译过linux下的
qt 和 KDE ?
那得要排放多少碳(co2)呀.
搞编译器的朋友表示动态语言理论极限会比静态语言快...
动态语言和静态语言有区别？
估计只有被伊莫金人聚能的码农才能写那种理论极限的编译器
70000 行是哪里来的 -__-
include 的问题可以用 stdafx/pch 解决, 现在很多 C++ 编译器已经优化过 include 了, 还拿好多年前的状况来说事...
与其说 Go 减少 pkg 的依赖, 不如说 Go 的 pkg 比 C++ 少太多, 当引入的 pkg 达到相同数量级的时候问题还是会出现.
C++ 在未定义的处理上更人性化, 打开 -Werror=unused 同样可以禁止定义未使用变量(不止是变量, 还有很细粒度的控制). 最终集成 build 打开就可以, 开发时那种限制就是恶心人. C++ 编译速度和链接速度是可以自己做主的, 如果想忽略掉链接期优化, 关闭编译器开关即可, 链接就快多了. 但是 Go 的设计决定就把需要链接期优化的人都一竿子打死了.
C++ parser 的二义问题都已经解决了. Go 的语法哪里便于优化?
这两贴把 go 程序员都钓出来了, 还要招人么?
插一句，go学习一下感觉代价还好，能处理解决现在所需的编程问题的话，个人还是可以接受的~
感谢各位，今天我学习了 :-)
c不会是高级汇编。。。
我觉得c的语法上和现代语言没什么区别，比如所谓oo，或者函数式编程，都可以用库的方式解决。
c的优势很现实，os，tcp/ip这类基础设施，都是由c写成的，外加可以完美结合asm，它作为系统级语言地位无法被动摇。我甚至觉得go是c的一种dsl。
嗯，我只是用这个比喻目前C和汇编的位置，将来就是Go和C的位置
性能当然是问题了。你做过运维么，如果go的性能是ruby的20倍，那就少20倍的机器，600台机器和30台机器管理起来不是一回事。
还有twitter之前不是都是ror么，后来切到JVM平台，也不宕机了，腰不酸了，腿不疼了，一口气上五楼了。
说解释运行比编译运行效率高，那也是只是说极限而已（而且是理论上的极限），jvm的JIT已经做了这么多年了，也没见真正达到C语言的水平。JIT编译器本身需要在编译速度和编译质量之间很好的权衡，未必就能做出最好的优化。不知道ruby的VM何时才能做到JVM水平。
一个C++版本的helloworld, VC2010展开后是70000行.
这个7万行是汇编的行数？
真的? 求截图
你是说每台机器的CPU或内存都是 满负荷运转的? 那就是硬件太落后了, 赛扬处理器.
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 &iostream&
int main() {
std::cout && "Hello, World!" && std::
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
stdafx/pch 已经说明了 include 的问题, 只是在补救而已. 再说如果代码在不同模块之间, 你愿意每个源文件被 stdafx/pch fuck 一次吗?
你还没有理解我说的意思: 如果pkg在一定数量之后, C/C++的每个库绝对会被include多次, 而依赖是树形结构, 这个是指数的差别.
又是一个语言的问题, 要靠编译器私活帮忙的例子. 你说的方法是语言标准吗, VC用户怎么办? Go语言如果需要运行速度的话, 可以期待gccgo的版本(这个运行速度优先级是高于编译速度的).
在解决二义问题时浪费了编译时间没有?
你觉得twitter这么穷么
twitter 是 5年前的, 确实慢, 硬件问题.
那您搞个五年之后的硬件把
c++写了个hello world展开确实会有70000行，但是Go展开的话也不少，这个不能说明问题，C++编译主要慢在上下文的解析，一旦引入模板就更悲剧了。
Go减少包的依赖这个无可争议的比C++牛逼很多，没有必要的pkg确实不需要引入，而C++就是一杆子打死引入很多无谓的包，而不是按需索取，当然C++也可以控制的很精细，但是这个代价非常大。
这一点Go的设计明显出于工程的考虑，没有使用的变量报错这是从编写代码阶段就防止隐藏的bug，这种unused的就必须报错
Go的二义可以精确的设计到这个， 你觉得Go的语法优化的不够吗？
终上所述，Go是一门让你降低心智，让程序员少犯错的工程性语言
做Web开发的，跟Go关系不大。不过Go的语法还不错，编译出来的也是a.out，很有linux下写c的感觉。
我觉得动态解释性语言，函数式编程语言要想在实际中达到理论上所描述的那样性能最终超越c还很遥远，haskell的一些专家也承认在很多情况下c写的代码更便于优化出更好的性能。我觉得要超越c，现在这种冯诺依曼架构的机器得发生大的变化，至少得向lisp机方向靠近一些，还有就是得等人工智能的技术有所突破才行。现在的编译器和人其实就是两对矛盾体，都在要求电脑给自己提供更大的方便。
C才不是最快的呢。C++ Fortran Ada Haskell都有比C快的单项。
说C快的根本就不懂C。
彻底对 70000 行无语了, 你也不看看 /E 选项是做什么的...
代价非常大, 花了我好几分钟...
你是在假设 C++ 程序员都不知道编译器输出的 warning: foo unused 是什么意思?
这篇文档根本就不是讲语法的啊! (跑题一下, go 的 func 语法根本没美感可言, 我是强迫症患者, top level 不能写 func literal 让我抓狂...)
关于语法的一些陈述不太对. 一般是先设计语法, 然后细化 parser. 优化的做法是减少回溯或者需要 look ahead 的部分, 对于 CFG 系列的(LL, LR, GLR等)语法不精细的地方, 解决方案就是找会有二义性的点添加断言, 并写进 spec 里表明哪一种更优先. go 里只有把类型写在后面的语法是有利于 parsing 的, 但那是其他语言长时间得来的经验, 也不是 go 特有的. 应该说 go 根本就没花多少心思在设计语法上.
我同意你降低心智的说法...
那些都已经超过了语言本身的界限，例如c++通过sse2指令实现的2叉树可以比c的快。这个网站的测试有很多限制条件，有很多的实现版本未必会被采纳。c很多情况下不如fortran这个老古董快倒是事实，但是也只限于intel的硬件上。
70000行只是说明每个源文件编译时都要展开很多重复的代码, 如果有很多源文件, 这是很浪费编译时间和硬盘空间的. include和模板都是编译器的速度杀手.
1. 首先我就说了7w行无关紧要，但是C++编译慢是必然的，你无需争辩
2. 你花了几分钟就解决了Google都无法解决的include依赖问题，算你狠
3. 一个是warning，一个是编译不通过，这就是不同层面的问题了，很多人吐槽这一点，但是我是人为从工程的角度来说，这是杜绝了隐藏bug
4. 你根本就不了解Go，Go的类型写后面不是为了parsing，看看最近许式伟在微博的解释吧，Go根本没化心思在设计语法上，说出这样的话只能让我觉得你有点自大了，也不看看Go的发明者都是谁，说他们不懂编译，二义性之类的就像你说Linus Torvalds不懂操作系统一样啊。
最后使用Go能够让程序员少犯很多错误，这个就让我们可以化更多的时间在其他上面
欢迎提供ruby的测试代码，还有Go的测试代码，我想自己测试一下，还有Go的测试，无需ioutil的包读取内容
照着 TechEmpower 写了个 Benchmark，比其他删掉了，就做了个查询的测试，结果取的是平均值接近的整数。
ab -n 1000 -c 10 http://localhost:3001/
ab -n 1000 -c 10 http://localhost:8080/
Requests per second: 6000 [#/sec] (mean)
Requests per second: 4000 [#/sec] (mean)
Go 是快，但是 Ruby 也没慢太多。
Benchmark一直都是很无聊的。。。。
忘了说一点了, Go的pkg变化不会导致间接依赖的pkg被重新编译. 如果你是用 stdafx.h 的机制, 那每次在 stdafx.h 改点代码之后, 编译时间会很痛苦吧.
头像配标题，真是一绝！
拿ruby和Go对比性能，我只能说别测试了，反而会很难堪，还有你并发打得少一点，那Go和ruby的性能还能很接近呢。
你们都上当了！
看 lz 的头像，这是一盘不小的棋啊！
之前是你扔出来说'专业'的测试机构，跟你说他测法不对，你说自己写，现在写了，结果也给了，你又说别测试了。有意思么？ 你拿Go和C比语言表达能力，和Ruby比性能，也真是会比啊。并发加到100也差不多。
我是觉得拿Go和ruby比性能没必要，只会让ruby自取其辱，你ab -n 100000 -c 10000测试测试
2个通通挂掉
那说明你的机器不行嘛，你慢慢加并发量试试看吧，这样也能说明稳定性、性能各方面的对比。还有当并发大了之后我感觉ab不行，你可以试试wrk这个工具，我觉得不错
看来还是java好啊
这种测试确实没啥意义，2个崩是掉数据库连接池不够。整个Web应用受影响的面太多了，数据库，缓存，集群，异步处理，关测试语言性能没意思。所以我前面也说了，这是很无聊的测试，跟helloworld没区别。
瓶颈在语言层面我不能说没有，但前面有太多层stack要经过，大部分瓶颈都会在前面。
不太同意，汇编和c的区别就像汽车和自行车，go和c的区别只是牌子不同的汽车而已。
学一下也好，重点是了解原理，这样也许自己就能开发出一种语言来。
照楼主的说法，Ruby China赶紧散伙了吧，哪天松本行弘走路上被车撞了，各位在Ruby上的投资就都打水漂了。Go是个开源项目，只要社区还有人支持它，跟Google放弃不放弃有什么关系么？
最近在看go，感觉还好，速度ruby根本没法比的，这个谁都知道，不过用习惯了ruby，用go很不习惯的感觉，没那么方便，速度开发还是ruby，也用了 的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
你的benchmark太弱了
这数据碉堡了，比我这i7 2600k的破机子nginx静态文件访问都快了，土豪我们做朋友好不好
七天七语言表示学点新语言没什么成本
关键Go现在能用来干嘛？服务端它目前一展身手的场合主要适合用erlang之类的，但erlang用的也不多。
Erlang推广策略有问题，问题很严重很严重
我是觉得语言是拿来用的，不说明应用场合的情况下，是否值得学习的必要性根本无从谈起。像Erlang是做高并发应用的，似乎是跟着几个NoSQL一起火的，之前冷了很多年；Ruby是借着Rails在Web开发火的，之前窝在日本无人知道，但出身也是linux的脚本语言；python是写算法、做运维脚本开始流行的。
Go究竟适合用来开发什么类型的软件？目前看下来，这东西肯定不是脚本类语言。
说得不错，合适的才是最好的。 说的twitter从ROR换JVM, 有几个公司会有这种问题？
Erlang推广最大的失败就是让人觉得它只适合高并发...
Go究竟适合用来开发什么类型的软件？目前看下来，这东西肯定不是脚本类语言。
Go的目标实际上和Ada差别不大。可惜Ada太早了，晚个几十年，加个Type Inference早就把Go轰成渣了
楼主的理由都不是理由
Ada 听说把 欧洲空间局阿丽亚娜5型运载火箭弄爆是什么情况？
我也歪楼下。。。。
Bill是坏小子，又再黑谷歌了，说Dart可能更切合些？
每次都是不知觉励 哎。。。 对C写东西，还从没又过。。。哎。。。
bill黑google，嗯。正常
现在一个tcp链接要用std::rt::io::net::tcp::TcpStream，美感在哪里？
use std::option::O
fn call_me_maybe(x: int) -& Option&int& {
代码写成这样还摆得出来。
--- 打字太曲折了！
怎样写比较好呢？
忘记哪位大牛说过，现在的语言性能都不会有太大提升，所以我感觉什么编的快 就用什么比较好！
我觉得就算google抛弃它，也还是会有很多爱好者继续研究的！
作为语言学习很好，不用作生产很好，很好~~~
161楼 已删除
这两贴把 go 程序员都钓出来了, 还要招人么?
招人啊，我们在用Go做，还在公测阶段，收费前入住的会一直免费，你们感受下 （不好意思，发广告发习惯了...)
不能同意太多. 硬件的发展,会淘汰一些语言.
硬件只是影响了语言的 执行效率 而已.没有影响语言的其他指标(比如体积大小,嵌入式方便否,设计初衷,适用领域等)
New SSA Backend for the Go Compiler
要换到SSA后端了
挺好的方向, 实现了么?
吵呀吵呀吵呀吵，吵到一个好基友！
说rust的目标就是为了写浏览器也是醉了。这么说，那些能自举的语言都只是为了写个编译器而已了。。。
说得好像Go在国外不火一样。起码感觉有在Web领域取代Python的潜力。
感觉Ruby才越来越小众了
一年前在使用Golang 也就是跟着国内流行的热风， 现在回头看 当时并不理智
赶紧sibi，Go 1.7 准备上 SSA 后端了
jun1st · #148 · 2 年前
说得不错，合适的才是最好的。 说的twitter从ROR换JVM, 有几个公司会有这种问题？
但凡压测的时候需要达到单机一千QPS的，都会有这个问题。
体量不够，就不会有这个问题。
典型的就是微博，电商。
目前的主流配置，Laravel这个丢脸的框架只能达到250-270，手工优化的PHP可以到一万，不过也分情况。
Java看业务，一般500到1000都可以。
至于ROR……
没具体数据，找到了这个。
（以前有博客提到，ruby给人的印象慢，是因为ror慢，难道是真哒？twitter不再出现鲸鱼了，是因为从ruby迁移到java，难道是真哒？）
个人觉得Go的简洁及并发性挺不错的，如果怕Google放弃也不太妥当，毕竟是开源项目了。Docker这么大的项目都出来了，一旦有了严肃的商业项目来应用某个语言，那么这个语言就有了很强的生存力，你Google不弄了，Docker社区的人也得弄下去。
所以我个人不赞赏这样有失偏颇的结论，同时也鼓励大家多学点东西，没必要非此即彼，所以我并不否定Go，但同时我也会建议去了解了解其他新语言，比如Rust，与其在这里斗嘴角，不如写点code，或者做点技术分享，我是Rust China社区
的创办者，我也曾经用Go写过一个公司的管理系统，都用用，都写写，你自然会知道自己喜欢什么，但也不要把自己的看法强加在别人身上。
这就是我的看法。
后方可回复, 如果你还没有账号请点击这里 。
共收到 173 条回复