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

[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 的包管理太脆弱了，在这种前提条件下，“去中心化”还没有讨论的必要。