粗大事了：花两天时间学习了 Go 语言，发现比 Node.js 高不知多少去了

[xhowhy]

先说感受到的先进性：

1. 语法非常简洁，有种在学 C 语言的感觉，学习过程觉得很轻松，没有太陡峭的曲线，但语言也完全够用
2. 自带工具就非常强大，而且各 IDE 和 Editor 都能集成，开发工具完全不是问题
   • go get = git clone + go install ，从 github 上直接 clone 下源码，编译出 .a 包文件和安装 bin 到 $GOPATH ，就可以本地任意地方使用了。反观 npm ，相信很多人不知道 NODE_PATH 的存在。
   • gofmt 代码风格统一，码农们再也不用为空格与 Tab 争吵了
   • go test 支持 benchmarks 和覆盖率测试
   • godoc 查看文档的工具。支持本地执行 godoc -http=:8080 后就能在浏览器中访问 golang.org 的本地 copy 版，对被墙的同学是个不错的选择
3. 支持 Github （ Gitlab 等也可以）远程包，不需要发布到类似 npm 那样的地方
4. 并发用协程和 channel 非常容易写，业务逻辑中可以尽量避免回调
5. 部署非常简单，可以运行二进制文件，也可以通过 go get 来安装 bin ，运维起来非常方便
6. API 稳定，据说从发布到现在语法基本没变，只是 Go 内部做了改进和优化
7. 本人还用 Swift 写过 iOS ，发现 Swift 似乎是从 Go 身上学了不少东西。。

劣势：

1. G...FF..WWW ，想下个 pkg 安装文件非常困难，最后是通过 brew 下载的
2. 国内资料少（这么简单的语言，似乎也不需要什么资料）
3. 社区小不如 npm ，国内想找个工作更是困难

不确定性：

1. 性能与 Java 比如何，相当于什么水平

综上所述，感觉 Go 确实是一个目前比较理想的开发工具，大家一起讨论讨论，人生苦短，为何不用 go ？

[bramblex]

学了两天就能指点江山了?

真牛。

[xhowhy]

@raincious 唉，你说得对，基于 URL 的包管理确实太脆弱了。。虽然 github 不容易挂，但如果有一个类似 npm registry 那样的设计，对 github 的依赖就会减弱，会更加地去“中心化”

[xhowhy]

@bramblex 呵呵，不服来辩。。喷谁不会，敢问你写过几年 node.js ？用 node 写的网站 pv 多少？

[xhowhy]

@bramblex 或许你可以先解答一下我的疑惑， callback 与 coroutine + channel 比，有何优势？

[CRVV]

@xhowhy
我知道的优势有 1 个
单线程、异步、使用 callback 的情况下，通常不需要互斥锁，也就是类似 atomic.AddXxx 的东西

当然劣势就多了去了

[dphdjy]

@xhowhy 既然确定 nodejs 没有优势，那就说明你所在的领域用不上，那就没什么可是说的了... 学好要用的就好，语言本身就是工具，问题在于环境和开发者本身，举个例子

> 如果你不相信我，可以看看这个叫“ Bocker ”的项目，它只用了 100 行 shell script ，就实现了 Docker 最重要的功能。 说白了， Docker 的原理就是建立一些目录，把系统文件和相关库代码拷贝进去，然后 chroot ，这样你的代码在里面运行的时候，就以为自己独占一个 Linux 系统。 Shell 语言之恶劣，我已经有专文介绍，所以就不多说了。本来可以用 shell 脚本实现的项目，现在有人用 Go 来做，能说明 Go 是一个好的语言吗？

EOF

[chai2010]

@xhowhy github 挂了影响也不是致命的，只要本地有一份，或者直接解析 import path 的协议，
或者是 vendor 包含 1 份（ url 只是一个 import path ， github 挂掉并补影响 gopath 的工作，最多时影响 Go get 而已）。


中心话的问题是，某个被大量使用的包稍微做个邪恶的改动就会导致整个社区挂掉（参考前几天 npm 的事故）。
vendor 虽然对版本没那么友好，但是可以完全隔离依赖包改动对当前包的影响。

[xhowhy]

@CRVV 说到不用锁，反而是 Go 的优势了。。

详情请看这篇文章的最后一个代码例子： http://ibillxia.github.io/blog/2014/03/16/go-concurrent-programming-first-try/
通过 coroutine + channel ，实现了无锁的并发。

看了这个例子，什么 async.parallel (async.js) 、 yield [].map (co 2.0) 、 Promise.all() 顿时黯然失色。。身不由己被宇宙的黑洞吸进去了，粉身碎骨

[xhowhy]

@chai2010 其实 vendor 目前的功能在加载多版本上已经够用了，是 npm 把大家都惯坏了，没有回归到库版本管理的本质。。看来我要收回我刚才在 82 楼说的话。。
在 iOS 开发中 Carthage 就是一个新的去中心化的方案，现在比 Cocoapods 更被社区推崇的原因相信也是如此啊。。
期待 Go 1.6 正式开始 vendor 。。

[lichun]

你和他谈笑风生？

[flynngao]

go 的包管理太差了实在是

[xhowhy]

@flynngao 其实也没那么查，是 npm 灵活性太高了，也不是什么好事。。看我在 27 楼的回复吧

[qiu0130]

go logo 受不了。。。

[gamexg]

go 的确好用，静态类型编译时就查出来大部分问题。
python 动态类型后期维护比较痛苦。

go 包管理倒是还没碰到问题，见过通过 url 来控制版本的。

[xhowhy]

@gamexg node.js ES6 以后也支持静态类型了， eslint 可以做静态检测，上兼容 es6 的 TypeScript 也行。。

[china521]

只喜欢 Go/Java/C++ 这样的静态编译语言，语法提示，那叫一个爽, 其它的动态语言，从来没敢用在实际项目上过....只做为脚本语言来用来提高效率

[lightening]

完全没有版本控制，有人提交一个不兼容的改变就全毁了……

[loading]

楼主，不要变成嘴炮…

[xhowhy]

@loading 请结合上面的讨论认真思辩。。做服务端开发为何不用 go 要用 node.js ？

[loading]

@xhowhy 我也认同服务端用 go 。

到时，不可否认。像我这种业余的，只需要一门语言，通吃了前后端，还能开发客户端，这吸引力！