go 10 周年,支持 12 个系统， 10 种架构，有 100 万的 gopher,成绩斐然啊

[dbskcnc]

特别报导 https://blog.golang.org/10years

[mengzhuo]

鄙鹅厂已经决定去 Java，全上 Go 了……
然而老系统改造真是让人想死

[koebehshian]

交叉编译爽，真正的一份代码，到处运行；像脚本语言，不同的硬件上需要安装不同的运行库； C/C++需要不同的交叉编译器；

[missdeer]

@secretman 你运气不好，go 就一直拿编译速度作为设计目标之一的

[iPhoneXI]

@mengzhuo 为什么要去 Java 而不是去 C++啊

[mengzhuo]

@iPhoneXI C++ 还有大量拥趸，用法跟 Go 也没有多少交集。

[Navee]

@mengzhuo
继续维护前任的屎山肯定出不了绩效嘛，肯定是用新语言重构绩效来的最快
而且自己上去了也不用自己维护了[摊手]

[loqixh]

@zhyl 追求编译速度的语言怎么可能优化好...........

[cyannnna]

bilibili 的 golang 开源功不可没（狗头）

[Monad]

@dafengqi 来个可以复现的 case 呗

[u823tg]

@mengzhuo 全面去 还是一些项目

[mengzhuo]

@u823tg 别的 BG 不好说，反正破产鸡和云都在搞了。

[mengzhuo]

@Navee 那就错了，一听说 jdk 要收费，各个大佬都觉得是威胁了，毕竟体量在那。

[JamesMackerel]

@zhyl

据我的观察……我总觉得 go 编译器的开发者比起编译器优化，更加在意编译速度。这也是我写 go 写到现在一直不理解的一个问题，一般来说，十倍的编译速度来换运行时的速度都应该是可以接受的（对我来说），为啥他们那么在意编译速度呢。

[coolchen112]

@JamesMackerel 因为都是辣鸡苦手，编译的快出 bug 的几率高一些，出 bug 的几率高了，效率也就提高了（ bug 的总量不变，但是编译速度决定了 bug 的解决速度 23333333333 ）

[dtsdao]

从 Python 转 Go 真的太痛苦了...一堆乱七八糟的静态语言特性还得适应= =
但据说 Java 转 Go 就很爽，不过 Kotlin 不香吗？

[dbskcnc]

@JamesMackerel 其实也一直在优化的，gc,run time 还一直在改进，只能说需要做的工作太多了，go team 比较重视编译体验,这个真的是一个痛点，从 C++过来的人会深有体会

[JamesMackerel]

@dbskcnc 那我还真没怎么写过 C++……我对面那个写 C++ 的老哥总是跟我说，clang 它不香吗。当然我自己是没体会……

然后还听过有的公司因为 C++ 编译过于慢，所以自研编译器以期提高编译速度的。其实到了一定地步，编译器的速度确实会是一个很大的问题。但是其实在大部分情况下，其实编译速度都不应该成为主要的要考虑的点吧。

[Yoock]

🤣🤣🤣golang 和自己同一天生日

[1024G]

额，go 也是是个"老“语言了，还以为是最近几年的呢！

[tairan2006]

Go 的问题其实就剩下泛型了…新版本估计 2020 年就能出了吧