粗大事了：花两天时间学习了 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 ？

楼几度歪了，强调下，楼主初衷只是想讨论一下在服务端开发领域 Go 是不是比 Node.js 更合适的工具。。
不要歪楼提 Node.js 在 Atom 等客户端开发上的建树，更不要乱扣帽子说楼主是在指点江山。。
可以说说 Node.js 和 Go 互相都好在哪里， Go 到底是不是比 Node.js 更好的选择。。

[shierji]

回答最后一个问题 因为人生苦短我用 python ！ 哈哈

[tracyone]

为啥不是 go 比 javascript 高不知多少去?

[xhowhy]

Go 安装的时候需要手动配置 $GOPATH 和 $GOROOT ，在这种类似的地方，让开发者手动操作一下，反而有利于开发者理解整个体系， iOS 上的包管理工具 Carthage 似乎也是从中得到启发，才做了一个与 Cocospod 不一样的东西。
另外想想 npm 的多版本包管理机制，实在是宝宝心里苦，想想 node_modules 下各级子目录存在多个版本的相同模块，这样的代码运行到线上，是该多么心惊胆战的事情， node.js 搞 web 可能还是不太专业。。

[xhowhy]

@tracyone 我这里说的 go 是一个开发工具，功能上约等于 node.js + npm + ...一系列第三方模块

[loading]

go 没有 Eletron

[xhowhy]

@shierji 感觉 python 运维起来会挺苦的， pip setuptools easy_install …而且 GIL 存在也实现不了真正的多线程。。

[timothyye]

恭喜 lz 入坑……

[xhowhy]

@loading 嗯， Go 是服务端语言，暂时写不了客户端。。不过 electron 严格上来说不是 node.js 平台上独享的，毕竟还有 webkit 。
我自我纠正一下，这里只比较服务端编程，不 PK 其他领域。

[xhowhy]

@timothyye 入坑啥意思？ Go 很坑还是咋地？

[zonghua]

@xhowhy 然而 python 就是运维用来编工具的。不支持动态 lian   jie   ku

[21grams]

谷歌自己都不用

[for4]

受不了 gofmt , 弃

[pathletboy]

@21grams 那是你没看到谷歌在用，其实后台用的非常多，应该仅次于 python ，当然，我也可以举个在用的例子， GAE 。国内厂商也大量在使用，只是都非常低调。

[TangMonk]

试试 elixir

[aszxqw]

nodejs 的包管理 npm 完爆 go get

[RqPS6rhmP3Nyn3Tm]

C 语法很简洁吗……真的吗……楼主你确定……

[xhowhy]

@21grams 在用的： https://golang.org/doc/faq#Is_Google_using_go_internally

Is Google using Go internally?

Yes. There are now several Go programs deployed in production inside Google. A public example is the server behind golang.org. It's just the godoc document server running in a production configuration on Google App Engine.

Other examples include the Vitess system for large-scale SQL installations and Google's download server, dl.google.com, which delivers Chrome binaries and other large installables such as apt-get packages.

[aszxqw]

你现在可能觉得 go get 很好用，等你被各种依赖版本不一致折腾的欲仙欲死的时候，你就知道 npm 的版本管理多么好了。

[xhowhy]

@aszxqw 请教如何完爆

[xhowhy]

@BXIA C 的语法全世界最简洁啊。。这你都不知道

[vdo]

第三方包多不多

[aszxqw]

@xhowhy 见 18 楼。

[xhowhy]

@vdo 反观 npm 的缺点就是第三方包太多。。 go 的系统模块比 node.js 更强大一些

[pathletboy]

@aszxqw golang 1.5 开始有 vendor 机制，现在 go 1.6 已经默认开启，可以初步解决版本依赖问题，当然，在包管理上和 NPM 比起来，是有差距。

[miyuki]

No visible "this".

[RqPS6rhmP3Nyn3Tm]

@xhowhy 当你学 C 的时候虐得死去活来（尤其是指针），真的不觉得 C 比 Python 简洁……

[xhowhy]

@aszxqw Godep 是 Go 社区开发的一个包管理工具，似乎已经要集成到 Go 1.6 了，你说的问题可以解决，但方案应该不是变成下一个 npm 。你看看 npm3 后 npm 社区开始撸平目录了，还改进了 peerDependency 字段，但还是不能彻底解决一个项目下多版本混乱的问题。以后随着组件的慢慢升级，这个问题应该会被解决，但还需要时间。。

[aszxqw]

@pathletboy vendor 机制和 godep 一样都是把源码加入 git 管理。容易导致因为依赖的包多，导致本仓库代码巨大。
而没法做到像 npm 那样，可以直接通过 package.json 自动下载依赖版本。
go 的包管理诟病这么久，我还以为能在 1.5 开始会出现转机，但是目前看到 vendor 相对于 godep 没有任何改进，令人失望。

[xhowhy]

@BXIA 一直觉得指针挺 So easy 啊

[aszxqw]

@xhowhy 如果 godep 能有自动下载的功能，而不是把所有依赖都加入 git 自己管理。那么确实可以解决。
但是目前没有看到任何进展。

[pathletboy]

@BXIA 你说的不是语法问题， C 的语法简单是毫无疑问的，用不好指针的时候，你学 python ，也会被虐的死去活来， C 面向过程，而 python 面向对象，就这点上来说， python 不会比 C 简洁。

[zhuangzhuang1988]

调试呢， repl 呢。。

[RqPS6rhmP3Nyn3Tm]

@xhowhy
@pathletboy 受教了

[longaiwp]

@BXIA 不要对任何东西抱有信仰，任何！你要说简洁， C 真的就是简洁，甚至可以说简陋， Python 在易用性上高不知道哪里去了，也可以说是一种“简洁”，就好像你不能说 Osx 被文件管理和应用缺乏折磨就觉得 Osx 怎么样

[xhowhy]

@aszxqw 了解了， go get 设计上也是过于乐观了。

[ivenlee]

Python 挺好，就是谈起性能有点尴尬（别的动态语言不要笑！你们好不到哪里去）。

Go 在语法上有点像 Python+C ，而它是静态的，很多在 Python 很自然的用法可能在 Go 中未必是这样（等专家解释）
。
gofmt 挺好，规范手册很容易忘记，不同的团队可能有不同的规范，所以比较认同用工具来做这个工作。 Python 不需要这样的工具？把所有缩进删了真的能 format 回来吗？很好奇！

GoImports ？ import 了未使用的包是不能编译的,给个警告就好了嘛，等真正要发布的时候再一次 GoImports 不行吗？这么专制干什么？ 要知道啪啪啪的过程中多次被打断是什么样的滋味。

go run ./main 是不被支持的，而且 go run 是编译了放在 /tmp 中的，使用于相对路径的代码要注意点。还是老老实实 build 了之后再执行吧。

[raincious]

Golang 的 Vendor 机制还是不太成熟， NPM 这方面好太多了。希望未来 Golang 只使用 Vendor 机制来进行包管理，然后有个命名空间一样的东西，而不要用 URL 。

关于性能：
http://benchmarksgame.alioth.debian.org/u64q/go.html

还有跟 Rust 的比较：
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=rust

还有跟世界上最好的语言比较：
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=php

[quix]

赞扬一个东西时候一定要拖个尾巴贬低一样东西， 这种行为到底算什么病...

[Nixus]

@xhowhy 昨天刚刚下决心离开 go ，回到 php 的怀抱！这下好了，你一个帖子又把俺拉回去了！！！
指针 So easy +1

[aabbccli]

不喜欢 gofmt

[xhowhy]

@aszxqw
依赖包的源码要不要一起提交到 git 上的问题，其实 cocoapods 也有碰到过：[https://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control]( https://guides.cocoapods.org/using/using-cocoapods.html#should-i-check-the-pods-directory-into-source-control)
至今也是木有结论。

@raincious
另外如果不用 URL ，就不是就意味着需要一个中心节点来记录 alias?

[xhowhy]

@quix 当我是个标题党吧

[rrfeng]

不是说中国是世界上 go 最浪的地区么。

别的不知道，反正运维层面上新出的项目基本上都是 go 的了……

[jsyangwenjie]

感觉你在黑 golang 。。。

[xhowhy]

@Nixus php 是世界上最好的语言。。我也曾痴迷于它。但现在似乎不是主流了，爱折腾所以写起来比较没动力。

[fway]

@raincious 这个　＂ KB gz 　＂ 　指的是什么？　文件大小还是内存占用？

[dphdjy]

t 大都没完全离开 nodejs 。。。

[cc7756789]

其他的暂且不评论，标准库代码的质量真心好，当然和 Go 语法的简洁有一定关系。

[xjp]

@quix 同意 +1

[xhowhy]

@jsyangwenjie 其实俺有三年的 node.js 应用开发经验，我用 node.js 开发网站每天承接上千万的流量，用 node.js 开发的前端开发工具也是部门 50+人的团队都在用。。就是这两天学了点皮毛 Go 之后，发现这东西确有可取之处，想和大家讨论一下，让大家都了解了解嘛

[xhowhy]

@dphdjy 你们 t 大早就不要你了。。 koa 早就不是他维护了

[aszxqw]

@xhowhy 我就希望 golang 能出一个模仿 npm 的包管理工具，但是一直等等等都没有等到。

[orvice]

go get 包管理某些地方是优势吧，然而实际上用起来，还是很多不方便的，虽然第三方有办法解决，但是作为处女座，表示真的还不如 Google 搞个中心和的包管理。

[abscon]

@xhowhy 说 C 语言的语法全世界最简洁， LISP 笑了

[SlipStupig]

我这里有 ss 的代理， 128.199.98.86 ： 12306 aes-256-cfb pwd ： test123sS ，祝愿楼主早日学成

[xhowhy]

@orvice 去中心化应该是 google 的思路不会变了。。
把依赖的包源码一并提交到仓库是否更符合工程化的开发？因为切 tag 看老代码的时候不用再 install 依赖

[dphdjy]

@xhowhy 没说维护啊，只是说依然用到 nodejs
抛开语言优势瞎折腾的问题毫无意义

[orvice]

@ivenlee import 未使用的包，和 var 了未使用变量编译不过。。。
表示刚刚从 动态语言过来写也是这种感觉 233

不过现在习惯了...

[xhowhy]

@SlipStupig 谢谢 代理我有 我的意思是阻碍了 Go 在国内的推广

[orvice]

@xhowhy 用过各种包管理， go 的 vendor 特性反正我是不怎么喜欢......虽然貌似解决可以版本的问题，但是感觉真的还不如做个中心化的包管理来的好....

以上建立在强迫症之上...

[orvice]

@xhowhy 还有就是，说到代理....
安装一些放在 Google 自己服务器上被墙的包也是蛋疼...

如果不是在路由器上翻墙...

用 proxychains 去 go get 。。。不知道是那边的 bugs ，二级依赖经常 get 不下来....还得手工安装一些包....

[aszxqw]

@orvice 我也希望不如搞个中心化的包管理，比如 npm ，然后国内可以通过搭建镜像去解决，比如 cnpm 。
还有关于 import 未使用的包报错的事情，可以通过 goimport 插件来自动 import 和去 import 。

[xhowhy]

@dphdjy 不知你指的语言优势是什么，问题我觉得 node 相比 go 我感觉没优势啊，你说 callback go 人家也有，而且人家有更先进的 coroutine 和 channel 。。不用依赖什么 async.js 、 co 和 promise

[xhowhy]

@abscon 你屌哦

[vagary]

从来不参与语言比较，但是尼玛楼主你说的三条劣势完全没看出来是劣势。。。

[xhowhy]

@aszxqw maybe 这是正确姿势

[xhowhy]

@vagary 都不知道幽默

[xhowhy]

@orvice
@aszxqw

我说说 iOS 和 Mac 开发的依赖管理的三种方案：

1. cocospod 就是存在一个中心仓库 https://github.com/CocoaPods/Specs 但也同时支持引入 github 上的包。和 npm 一样， github 上也经常碰到熊孩子把 tag 删除的事故。
2. Carthage 就是一个去中心化的方案，现在更被推崇
3. SwiftPackage 似乎也是个一个去中心化的方案， Swift 2.2 刚推出的

[ivenlee]

golang.org 上的包我使用 git 从 github 的镜像中 clone 到$GOPATH 的，貌似没有问题。

[plqws]

最近在写一个基于 Electron 的 WYSIWYG 编辑器…不敢想象如果用 Go 写会是怎样的，所以还是术业有专攻吧。
要我说， Node 的服务端开发只是附赠品吧， Node 应该在客户端领域配合 Chromium 大显身手才对！
至于 Go ，我学了两天左右就被 C# 吸引走了…

[xhowhy]

说反了， Node 主要是为了服务端而生的 ，配合 Chromium 做桌面开发才是附赠品。。再说现在都是移动时代了，还有多少人热衷于用 Electron 写桌面 App 啊。。还是言归正传说服务端开发哈
C# 有毛好的俺不晓得，但我觉得 coroutine 和 channel 应该比 node.js 的 callback 好。。

[plqws]

@xhowhy 现在 Node 在服务端领域，我能在 10 秒内想到的开源软件，只有 NodeBB …
而在客户端上， Atom 、 VSCode 、 Docker Toolbox 、 N1 （还是什么的，一个邮件客户端，我把名字忘了）。我 Node 也主要是拿来做服务端开发，但是我也不知道我为什么会对 Node 服务端领域的产品的了解那么稀少。

[plqws]

@xhowhy C# 的话，好在强类型，语法简单（有 Java 基础转过去分分钟的事情），强大的标准库，各种高大上（以及还在不断从其他语言借鉴添加）的语言特性，微软爹， Visual Studio （配合 Resharper 风味更佳），不用怕被告等等……现在官方跨平台化也在进行中

[julor]

同意楼主所说！从此写多线程那都不是事！

[xhowhy]

@plqws 你说的是那些客户端软件都是属于专有领域（程序设计），相比较全世界的各种消费者业务领域，占比是比较低的。 Node.js 推出的时候之初就是为服务端而设计的，现在使用 express.js 和 koa 框架构建起来的网站数量不计其数，光是 BAT 用到 Node.js 的产品受众早就大大超过你列举的客户端软件用户数。
再顺便提一下， node-webkti 、 electron 和 atom 这类技术，无非是在 node.js 和 webkit 的 API 上做了 binding ， html/css/js 这部分渲染的内核还是浏览器引擎实现的， node.js 在其中起的作用其实比较小。。
**所以你还觉得 Node 的服务端开发只是附赠品吗？？**
另外你没有 get 到我的点诶，这个帖子旨在服务端领域比较 Go 与 Node.js ，不谈其他。否则就太复杂了。

[raincious]

@xhowhy
> 另外如果不用 URL ，就不是就意味着需要一个中心节点来记录 alias?

不需要。基于 Vendor+Namespace 的包管理不会有中心化的问题。包仓库其实可以做成仅仅只是一个协议，然后你就完全可以根据那个协议自己建立一个 Registry ，然后让项目依赖那个 Registry 或者多个 Registry 。剩下的就是按照优先级解决这些 Registry 中存在的同名包了。

你看， Nodejs 的 npm 和 PHP 的 Composer 都可以修改 Registry 的地址：
https://docs.npmjs.com/misc/registry
https://getcomposer.org/doc/04-schema.md#repositories

如果 npm 或者 packagist 某天不能用了，改一个地址就能用其他的 Registry 了。

@fway
KB ： Memory usage in KB
gz ： File size after gziping
http://benchmarksgame.alioth.debian.org/how-programs-are-measured.html

[wph95]

@plqws docker toolbox 跟 node 有毛关系
只是 Kitematic 用 electron 罢了
Docker 全家都是 go | python

[xhowhy]

@raincious Registry 还是中心啊。。否则就不会有 npm 和私有 npm scope （@group/xxx ）的区别了。私有 npm 本质还是需要同步公网 npm 的东西的，只是在 scope 下发布自己的模块。模块名前还要加 @groupName/ 前缀。
而 cnpm 可以理解成 npm 的镜像，不算私有 npm 。
总之， npm 离开 registry 就不行鸟~还是中心

[Nixus]

@xhowhy 现在还要靠 php 吃饭呢！不说 php 坏话！哈哈哈……赶紧折腾完 docker ，折腾 go

[raincious]

@xhowhy

所以同理， GitHub 要是某天挂了或者更改了 URL ，那么所有依赖 GitHub 上 package 的都要也得挂。别忘了之前大家用 Google Code 用的也是很 Happy 的。而且哪怕 GitHub 挂掉的可能性不大，自建 GitLab 上的那些包呢？

所以 Golang 这种管理方式根本也不叫去中心化。

基于 URL 的包管理太脆弱了，在这种前提条件下，“去中心化”还没有讨论的必要。

[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 。

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