Nodejs与Go语言比较，发现Go语言强大太多，花两天时间学习后的感慨
Nodejs与Go语言比较，发现Go语言强大太多，花两天时间学习后的感慨
先说感受到的先进性：
- 语法非常简洁，有种在学 C 语言的感觉，学习过程觉得很轻松，没有太陡峭的曲线，但语言也完全够用
- 自带工具就非常强大，而且各 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 版，对被墙的同学是个不错的选择
- 支持 Github （ Gitlab 等也可以）远程包，不需要发布到类似 npm 那样的地方
- 并发用协程和 channel 非常容易写，业务逻辑中可以尽量避免回调
- 部署非常简单，可以运行二进制文件，也可以通过 go get 来安装 bin ，运维起来非常方便
- API 稳定，据说从发布到现在语法基本没变，只是 Go 内部做了改进和优化
- 本人还用 Swift 写过 iOS ，发现 Swift 似乎是从 Go 身上学了不少东西。。
劣势：
- G...FF..WWW ，想下个 pkg 安装文件非常困难，最后是通过 brew 下载的
- 国内资料少（这么简单的语言，似乎也不需要什么资料）
- 社区小不如 npm ，国内想找个工作更是困难
不确定性：
- 性能与 Java 比如何，相当于什么水平
综上所述，感觉 Go 确实是一个目前比较理想的开发工具，大家一起讨论讨论，人生苦短，为何不用 go ？
Go 安装的时候需要手动配置 $GOPATH 和 $GOROOT ，在这种类似的地方，让开发者手动操作一下，反而有利于开发者理解整个体系， iOS 上的包管理工具 Carthage 似乎也是从中得到启发，才做了一个与 Cocospod 不一样的东西。
另外想想 npm 的多版本包管理机制，实在是宝宝心里苦，想想 node_modules 下各级子目录存在多个版本的相同模块，这样的代码运行到线上，是该多么心惊胆战的事情， node.js 搞 web 可能还是不太专业。。
嗯， Go 是服务端语言，暂时写不了客户端。。不过 electron 严格上来说不是 node.js 平台上独享的，毕竟还有 webkit 。
我自我纠正一下，这里只比较服务端编程，不 PK 其他领域。
在用的： 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.
Godep 是 Go 社区开发的一个包管理工具，似乎已经要集成到 Go 1.6 了，你说的问题可以解决，但方案应该不是变成下一个 npm 。你看看 npm3 后 npm 社区开始撸平目录了，还改进了 peerDependency 字段，但还是不能彻底解决一个项目下多版本混乱的问题。以后随着组件的慢慢升级，这个问题应该会被解决，但还需要时间。。
vendor 机制和 godep 一样都是把源码加入 git 管理。容易导致因为依赖的包多，导致本仓库代码巨大。
而没法做到像 npm 那样，可以直接通过 package.json 自动下载依赖版本。
go 的包管理诟病这么久，我还以为能在 1.5 开始会出现转机，但是目前看到 vendor 相对于 godep 没有任何改进，令人失望。
你说的不是语法问题， C 的语法简单是毫无疑问的，用不好指针的时候，你学 python ，也会被虐的死去活来， C 面向过程，而 python 面向对象，就这点上来说， python 不会比 C 简洁。
不要对任何东西抱有信仰，任何！你要说简洁， C 真的就是简洁，甚至可以说简陋， Python 在易用性上高不知道哪里去了，也可以说是一种“简洁”，就好像你不能说 Osx 被文件管理和应用缺乏折磨就觉得 Osx 怎么样
Python 挺好，就是谈起性能有点尴尬（别的动态语言不要笑！你们好不到哪里去）。
Go 在语法上有点像 Python+C ，而它是静态的，很多在 Python 很自然的用法可能在 Go 中未必是这样（等专家解释）
。
gofmt 挺好，规范手册很容易忘记，不同的团队可能有不同的规范，所以比较认同用工具来做这个工作。 Python 不需要这样的工具？把所有缩进删了真的能 format 回来吗？很好奇！
GoImports ？ import 了未使用的包是不能编译的,给个警告就好了嘛，等真正要发布的时候再一次 GoImports 不行吗？这么专制干什么？ 要知道啪啪啪的过程中多次被打断是什么样的滋味。
go run ./main 是不被支持的，而且 go run 是编译了放在 /tmp 中的，使用于相对路径的代码要注意点。还是老老实实 build 了之后再执行吧。
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
依赖包的源码要不要一起提交到 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)
至今也是木有结论。
另外如果不用 URL ，就不是就意味着需要一个中心节点来记录 alias?
其实俺有三年的 node.js 应用开发经验，我用 node.js 开发网站每天承接上千万的流量，用 node.js 开发的前端开发工具也是部门 50+人的团队都在用。。就是这两天学了点皮毛 Go 之后，发现这东西确有可取之处，想和大家讨论一下，让大家都了解了解嘛
go get 包管理某些地方是优势吧，然而实际上用起来，还是很多不方便的，虽然第三方有办法解决，但是作为处女座，表示真的还不如 Google 搞个中心和的包管理。
用过各种包管理， go 的 vendor 特性反正我是不怎么喜欢…虽然貌似解决可以版本的问题，但是感觉真的还不如做个中心化的包管理来的好…
以上建立在强迫症之上…
还有就是，说到代理…
安装一些放在 Google 自己服务器上被墙的包也是蛋疼…
如果不是在路由器上翻墙…
用 proxychains 去 go get 。。。不知道是那边的 bugs ，二级依赖经常 get 不下来…还得手工安装一些包…
我也希望不如搞个中心化的包管理，比如 npm ，然后国内可以通过搭建镜像去解决，比如 cnpm 。
还有关于 import 未使用的包报错的事情，可以通过 goimport 插件来自动 import 和去 import 。
我说说 iOS 和 Mac 开发的依赖管理的三种方案：
1. cocospod 就是存在一个中心仓库 https://github.com/CocoaPods/Specs 但也同时支持引入 github 上的包。和 npm 一样， github 上也经常碰到熊孩子把 tag 删除的事故。
2. Carthage 就是一个去中心化的方案，现在更被推崇
3. SwiftPackage 似乎也是个一个去中心化的方案， Swift 2.2 刚推出的
最近在写一个基于 Electron 的 WYSIWYG 编辑器…不敢想象如果用 Go 写会是怎样的，所以还是术业有专攻吧。
要我说， Node 的服务端开发只是附赠品吧， Node 应该在客户端领域配合 Chromium 大显身手才对！
至于 Go ，我学了两天左右就被 C# 吸引走了…
说反了， Node 主要是为了服务端而生的 ，配合 Chromium 做桌面开发才是附赠品。。再说现在都是移动时代了，还有多少人热衷于用 Electron 写桌面 App 啊。。还是言归正传说服务端开发哈
C# 有毛好的俺不晓得，但我觉得 coroutine 和 channel 应该比 node.js 的 callback 好。。
现在 Node 在服务端领域，我能在 10 秒内想到的开源软件，只有 NodeBB …
而在客户端上， Atom 、 VSCode 、 Docker Toolbox 、 N1 （还是什么的，一个邮件客户端，我把名字忘了）。我 Node 也主要是拿来做服务端开发，但是我也不知道我为什么会对 Node 服务端领域的产品的了解那么稀少。
C# 的话，好在强类型，语法简单（有 Java 基础转过去分分钟的事情），强大的标准库，各种高大上（以及还在不断从其他语言借鉴添加）的语言特性，微软爹， Visual Studio （配合 Resharper 风味更佳），不用怕被告等等……现在官方跨平台化也在进行中
你说的是那些客户端软件都是属于专有领域（程序设计），相比较全世界的各种消费者业务领域，占比是比较低的。 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 ，不谈其他。否则就太复杂了。
> 另外如果不用 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 了。
KB ： Memory usage in KB
gz ： File size after gziping
http://benchmarksgame.alioth.debian.org/how-programs-are-measured.html
Registry 还是中心啊。。否则就不会有 npm 和私有 npm scope （group/xxx ）的区别了。私有 npm 本质还是需要同步公网 npm 的东西的，只是在 scope 下发布自己的模块。模块名前还要加 / 前缀。
而 cnpm 可以理解成 npm 的镜像，不算私有 npm 。
总之， npm 离开 registry 就不行鸟~还是中心
所以同理， GitHub 要是某天挂了或者更改了 URL ，那么所有依赖 GitHub 上 package 的都要也得挂。别忘了之前大家用 Google Code 用的也是很 Happy 的。而且哪怕 GitHub 挂掉的可能性不大，自建 GitLab 上的那些包呢？
所以 Golang 这种管理方式根本也不叫去中心化。
基于 URL 的包管理太脆弱了，在这种前提条件下，“去中心化”还没有讨论的必要。
唉，你说得对，基于 URL 的包管理确实太脆弱了。。虽然 github 不容易挂，但如果有一个类似 npm registry 那样的设计，对 github 的依赖就会减弱，会更加地去“中心化”
既然确定 nodejs 没有优势，那就说明你所在的领域用不上，那就没什么可是说的了… 学好要用的就好，语言本身就是工具，问题在于环境和开发者本身，举个例子
> 如果你不相信我，可以看看这个叫“ Bocker ”的项目，它只用了 100 行 shell script ，就实现了 Docker 最重要的功能。 说白了， Docker 的原理就是建立一些目录，把系统文件和相关库代码拷贝进去，然后 chroot ，这样你的代码在里面运行的时候，就以为自己独占一个 Linux 系统。 Shell 语言之恶劣，我已经有专文介绍，所以就不多说了。本来可以用 shell 脚本实现的项目，现在有人用 Go 来做，能说明 Go 是一个好的语言吗？
EOF
github 挂了影响也不是致命的，只要本地有一份，或者直接解析 import path 的协议，
或者是 vendor 包含 1 份（ url 只是一个 import path ， github 挂掉并补影响 gopath 的工作，最多时影响 Go get 而已）。
中心话的问题是，某个被大量使用的包稍微做个邪恶的改动就会导致整个社区挂掉（参考前几天 npm 的事故）。
vendor 虽然对版本没那么友好，但是可以完全隔离依赖包改动对当前包的影响。
说到不用锁，反而是 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() 顿时黯然失色。。身不由己被宇宙的黑洞吸进去了，粉身碎骨
在对比Node.js与Go语言时，确实能感受到两者在设计哲学和性能表现上的差异。Go语言作为一门编译型语言，在并发处理、内存管理和系统级编程方面确实有其独特优势。以下是一些关键点，以及简单的代码示例来展示这种差异。
并发处理
Node.js采用事件驱动的非阻塞I/O模型，擅长处理大量并发连接，但在CPU密集型任务上可能表现不佳。Go语言则通过goroutine和channel提供了高效的并发模型。
Go语言示例（并发求和）：
package main
import (
"fmt"
"sync"
)
func main() {
var wg sync.WaitGroup
sum := 0
for i := 0; i < 1000; i++ {
wg.Add(1)
go func(n int) {
defer wg.Done()
sum += n
}(i)
}
wg.Wait()
fmt.Println("Sum:", sum)
}
性能
Go语言由于是编译型语言，通常比Node.js（解释型+V8引擎）具有更高的运行效率，特别是在处理大量计算任务时。
内存管理
Go语言有自动垃圾回收机制，减少了内存泄漏的风险，同时提供了更精细的内存控制选项。
总的来说，Go语言在并发处理、性能和内存管理方面确实有其优势。然而，选择哪种语言还需根据具体项目需求来决定。Node.js在开发速度、生态系统丰富度和前端开发集成方面也有其独到之处。
