粗大事了：花两天时间学习了 Go 语言，发现比 Node.js 高不知多少去了
xhowhy · 2016-04-03 16:19:20 +08:00 · 54019 次点击这是一个创建于 3157 天前的主题，其中的信息可能已经有所发展或是发生改变。
先说感受到的先进性：
- 语法非常简洁，有种在学 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 ？
第 1 条附言 · 2016-04-03 23:25:43 +08:00
楼几度歪了，强调下，楼主初衷只是想讨论一下在服务端开发领域 Go 是不是比 Node.js 更合适的工具。。
不要歪楼提 Node.js 在 Atom 等客户端开发上的建树，更不要乱扣帽子说楼主是在指点江山。。
可以说说 Node.js 和 Go 互相都好在哪里， Go 到底是不是比 Node.js 更好的选择。。
不要歪楼提 Node.js 在 Atom 等客户端开发上的建树，更不要乱扣帽子说楼主是在指点江山。。
可以说说 Node.js 和 Go 互相都好在哪里， Go 到底是不是比 Node.js 更好的选择。。
 |
1
shierji 2016-04-03 16:23:37 +08:00  1
回答最后一个问题 因为人生苦短我用 python ！ 哈哈
|
 |
2
tracyone 2016-04-03 16:25:37 +08:00 via Android 2
为啥不是 go 比 javascript 高不知多少去?
|
 |
3
xhowhy OP Go 安装的时候需要手动配置 $GOPATH 和 $GOROOT ，在这种类似的地方，让开发者手动操作一下，反而有利于开发者理解整个体系， iOS 上的包管理工具 Carthage 似乎也是从中得到启发，才做了一个与 Cocospod 不一样的东西。
另外想想 npm 的多版本包管理机制，实在是宝宝心里苦，想想 node_modules 下各级子目录存在多个版本的相同模块，这样的代码运行到线上，是该多么心惊胆战的事情， node.js 搞 web 可能还是不太专业。。 |
|
4
xhowhy OP @tracyone 我这里说的 go 是一个开发工具，功能上约等于 node.js + npm + ...一系列第三方模块
|
 |
5
loading 2016-04-03 16:30:19 +08:00 via Android
go 没有 Eletron
|
|
6
xhowhy OP @shierji 感觉 python 运维起来会挺苦的， pip setuptools easy_install …而且 GIL 存在也实现不了真正的多线程。。
|
 |
7
timothyye 2016-04-03 16:35:42 +08:00
恭喜 lz 入坑……
|
|
8
xhowhy OP @loading 嗯， Go 是服务端语言，暂时写不了客户端。。不过 electron 严格上来说不是 node.js 平台上独享的，毕竟还有 webkit 。
我自我纠正一下，这里只比较服务端编程，不 PK 其他领域。 |
 |
11
21grams 2016-04-03 16:41:50 +08:00
谷歌自己都不用
|
 |
12
for4 2016-04-03 16:45:03 +08:00
受不了 gofmt , 弃
|
 |
13
pathletboy 2016-04-03 16:45:05 +08:00
@21grams 那是你没看到谷歌在用，其实后台用的非常多，应该仅次于 python ，当然，我也可以举个在用的例子， GAE 。国内厂商也大量在使用，只是都非常低调。
|
 |
14
TangMonk 2016-04-03 16:47:52 +08:00
试试 elixir
|
 |
15
aszxqw 2016-04-03 16:49:38 +08:00
nodejs 的包管理 npm 完爆 go get
|
 |
16
RqPS6rhmP3Nyn3Tm 2016-04-03 16:50:08 +08:00 via iPad
C 语法很简洁吗……真的吗……楼主你确定……
|
|
17
xhowhy OP @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. |
|
18
aszxqw 2016-04-03 16:50:36 +08:00
你现在可能觉得 go get 很好用，等你被各种依赖版本不一致折腾的欲仙欲死的时候，你就知道 npm 的版本管理多么好了。
|
 |
21
vdo 2016-04-03 16:56:59 +08:00
第三方包多不多
|
|
24
pathletboy 2016-04-03 17:00:33 +08:00
@aszxqw golang 1.5 开始有 vendor 机制，现在 go 1.6 已经默认开启，可以初步解决版本依赖问题，当然，在包管理上和 NPM 比起来，是有差距。
|
 |
25
miyuki 2016-04-03 17:01:31 +08:00 via Android
No visible "this".
|
|
26
RqPS6rhmP3Nyn3Tm 2016-04-03 17:03:32 +08:00
@xhowhy 当你学 C 的时候虐得死去活来（尤其是指针），真的不觉得 C 比 Python 简洁……
|
|
27
xhowhy OP 1
@aszxqw Godep 是 Go 社区开发的一个包管理工具，似乎已经要集成到 Go 1.6 了，你说的问题可以解决，但方案应该不是变成下一个 npm 。你看看 npm3 后 npm 社区开始撸平目录了，还改进了 peerDependency 字段，但还是不能彻底解决一个项目下多版本混乱的问题。以后随着组件的慢慢升级，这个问题应该会被解决，但还需要时间。。
|
|
28
aszxqw 2016-04-03 17:05:52 +08:00
@pathletboy vendor 机制和 godep 一样都是把源码加入 git 管理。容易导致因为依赖的包多，导致本仓库代码巨大。
而没法做到像 npm 那样，可以直接通过 package.json 自动下载依赖版本。 go 的包管理诟病这么久，我还以为能在 1.5 开始会出现转机，但是目前看到 vendor 相对于 godep 没有任何改进，令人失望。 |
|
30
aszxqw 2016-04-03 17:07:39 +08:00
@xhowhy 如果 godep 能有自动下载的功能，而不是把所有依赖都加入 git 自己管理。那么确实可以解决。
但是目前没有看到任何进展。 |
|
31
pathletboy 2016-04-03 17:09:09 +08:00
@BXIA 你说的不是语法问题， C 的语法简单是毫无疑问的，用不好指针的时候，你学 python ，也会被虐的死去活来， C 面向过程，而 python 面向对象，就这点上来说， python 不会比 C 简洁。
|
 |
32
zhuangzhuang1988 2016-04-03 17:10:58 +08:00
调试呢， repl 呢。。
|
|
33
RqPS6rhmP3Nyn3Tm 2016-04-03 17:12:35 +08:00 via iPad
|
 |
34
longaiwp 2016-04-03 17:15:54 +08:00 2
@BXIA 不要对任何东西抱有信仰，任何！你要说简洁， C 真的就是简洁，甚至可以说简陋， Python 在易用性上高不知道哪里去了，也可以说是一种“简洁”，就好像你不能说 Osx 被文件管理和应用缺乏折磨就觉得 Osx 怎么样
|
 |
36
ivenlee 2016-04-03 17:16:00 +08:00
Python 挺好，就是谈起性能有点尴尬（别的动态语言不要笑！你们好不到哪里去）。
Go 在语法上有点像 Python+C ，而它是静态的，很多在 Python 很自然的用法可能在 Go 中未必是这样（等专家解释） 。 gofmt 挺好，规范手册很容易忘记，不同的团队可能有不同的规范，所以比较认同用工具来做这个工作。 Python 不需要这样的工具？把所有缩进删了真的能 format 回来吗？很好奇！ GoImports ？ import 了未使用的包是不能编译的,给个警告就好了嘛，等真正要发布的时候再一次 GoImports 不行吗？这么专制干什么？ 要知道啪啪啪的过程中多次被打断是什么样的滋味。 go run ./main 是不被支持的，而且 go run 是编译了放在 /tmp 中的，使用于相对路径的代码要注意点。还是老老实实 build 了之后再执行吧。 |
 |
37
raincious 2016-04-03 17:16:02 +08:00
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 |
 |
38
quix 2016-04-03 17:18:47 +08:00 3
赞扬一个东西时候一定要拖个尾巴贬低一样东西， 这种行为到底算什么病...
|
 |
39
Nixus 2016-04-03 17:18:57 +08:00
@xhowhy 昨天刚刚下决心离开 go ，回到 php 的怀抱！这下好了，你一个帖子又把俺拉回去了！！！
指针 So easy +1 |
 |
40
aabbccli 2016-04-03 17:24:04 +08:00
不喜欢 gofmt
|
|
41
xhowhy OP @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? |
 |
43
rrfeng 2016-04-03 17:28:44 +08:00
不是说中国是世界上 go 最浪的地区么。
别的不知道，反正运维层面上新出的项目基本上都是 go 的了…… |
 |
44
jsyangwenjie 2016-04-03 17:30:54 +08:00
感觉你在黑 golang 。。。
|
 |
47
dphdjy 2016-04-03 17:33:36 +08:00 via Android
t 大都没完全离开 nodejs 。。。
|
 |
48
cc7756789 2016-04-03 17:34:33 +08:00
其他的暂且不评论，标准库代码的质量真心好，当然和 Go 语法的简洁有一定关系。
|
|
50
xhowhy OP @jsyangwenjie 其实俺有三年的 node.js 应用开发经验，我用 node.js 开发网站每天承接上千万的流量，用 node.js 开发的前端开发工具也是部门 50+人的团队都在用。。就是这两天学了点皮毛 Go 之后，发现这东西确有可取之处，想和大家讨论一下，让大家都了解了解嘛
|
 |
53
orvice 2016-04-03 17:40:23 +08:00
go get 包管理某些地方是优势吧，然而实际上用起来，还是很多不方便的，虽然第三方有办法解决，但是作为处女座，表示真的还不如 Google 搞个中心和的包管理。
|
 |
55
SlipStupig 2016-04-03 17:43:33 +08:00
我这里有 ss 的代理， 128.199.98.86 ： 12306 aes-256-cfb pwd ： test123sS ，祝愿楼主早日学成
|
|
56
xhowhy OP @orvice 去中心化应该是 google 的思路不会变了。。
把依赖的包源码一并提交到仓库是否更符合工程化的开发？因为切 tag 看老代码的时候不用再 install 依赖 |
|
58
orvice 2016-04-03 17:44:18 +08:00
|
|
59
xhowhy OP @SlipStupig 谢谢 代理我有 我的意思是阻碍了 Go 在国内的推广
|
|
60
orvice 2016-04-03 17:47:39 +08:00
|
|
61
orvice 2016-04-03 17:49:22 +08:00
@xhowhy 还有就是，说到代理....
安装一些放在 Google 自己服务器上被墙的包也是蛋疼... 如果不是在路由器上翻墙... 用 proxychains 去 go get 。。。不知道是那边的 bugs ，二级依赖经常 get 不下来....还得手工安装一些包.... |
|
62
aszxqw 2016-04-03 17:49:22 +08:00
@orvice 我也希望不如搞个中心化的包管理，比如 npm ，然后国内可以通过搭建镜像去解决，比如 cnpm 。
还有关于 import 未使用的包报错的事情，可以通过 goimport 插件来自动 import 和去 import 。 |
|
63
xhowhy OP @dphdjy 不知你指的语言优势是什么，问题我觉得 node 相比 go 我感觉没优势啊，你说 callback go 人家也有，而且人家有更先进的 coroutine 和 channel 。。不用依赖什么 async.js 、 co 和 promise
|
 |
65
vagary 2016-04-03 17:51:27 +08:00
从来不参与语言比较，但是尼玛楼主你说的三条劣势完全没看出来是劣势。。。
|
|
68
xhowhy OP @orvice
@aszxqw 我说说 iOS 和 Mac 开发的依赖管理的三种方案： 1. cocospod 就是存在一个中心仓库 https://github.com/CocoaPods/Specs 但也同时支持引入 github 上的包。和 npm 一样， github 上也经常碰到熊孩子把 tag 删除的事故。 2. Carthage 就是一个去中心化的方案，现在更被推崇 3. SwiftPackage 似乎也是个一个去中心化的方案， Swift 2.2 刚推出的 |
|
69
ivenlee 2016-04-03 18:04:01 +08:00
golang.org 上的包我使用 git 从 github 的镜像中 clone 到$GOPATH 的，貌似没有问题。
|
 |
70
plqws 2016-04-03 18:06:21 +08:00
最近在写一个基于 Electron 的 WYSIWYG 编辑器…不敢想象如果用 Go 写会是怎样的，所以还是术业有专攻吧。
要我说， Node 的服务端开发只是附赠品吧， Node 应该在客户端领域配合 Chromium 大显身手才对！ 至于 Go ，我学了两天左右就被 C# 吸引走了… |
|
71
xhowhy OP 说反了， Node 主要是为了服务端而生的 ，配合 Chromium 做桌面开发才是附赠品。。再说现在都是移动时代了，还有多少人热衷于用 Electron 写桌面 App 啊。。还是言归正传说服务端开发哈
C# 有毛好的俺不晓得，但我觉得 coroutine 和 channel 应该比 node.js 的 callback 好。。 |
|
72
plqws 2016-04-03 18:24:59 +08:00
@xhowhy 现在 Node 在服务端领域，我能在 10 秒内想到的开源软件，只有 NodeBB …
而在客户端上， Atom 、 VSCode 、 Docker Toolbox 、 N1 （还是什么的，一个邮件客户端，我把名字忘了）。我 Node 也主要是拿来做服务端开发，但是我也不知道我为什么会对 Node 服务端领域的产品的了解那么稀少。 |
|
73
plqws 2016-04-03 18:29:46 +08:00
@xhowhy C# 的话，好在强类型，语法简单（有 Java 基础转过去分分钟的事情），强大的标准库，各种高大上（以及还在不断从其他语言借鉴添加）的语言特性，微软爹， Visual Studio （配合 Resharper 风味更佳），不用怕被告等等……现在官方跨平台化也在进行中
|
 |
74
julor 2016-04-03 18:38:39 +08:00 via Android
同意楼主所说！从此写多线程那都不是事！
|
|
75
xhowhy OP @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 ，不谈其他。否则就太复杂了。 |
|
76
raincious 2016-04-03 18:42:06 +08:00
@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 |
 |
77
wph95 2016-04-03 18:46:53 +08:00
|
|
78
xhowhy OP |
|
80
raincious 2016-04-03 19:07:30 +08:00
@xhowhy
所以同理， GitHub 要是某天挂了或者更改了 URL ，那么所有依赖 GitHub 上 package 的都要也得挂。别忘了之前大家用 Google Code 用的也是很 Happy 的。而且哪怕 GitHub 挂掉的可能性不大，自建 GitLab 上的那些包呢？ 所以 Golang 这种管理方式根本也不叫去中心化。 基于 URL 的包管理太脆弱了，在这种前提条件下，“去中心化”还没有讨论的必要。 |
 |
81
bramblex 2016-04-03 19:13:37 +08:00
学了两天就能指点江山了?
真牛。 |
|
82
xhowhy OP @raincious 唉，你说得对，基于 URL 的包管理确实太脆弱了。。虽然 github 不容易挂，但如果有一个类似 npm registry 那样的设计，对 github 的依赖就会减弱，会更加地去“中心化”
|
|
84
xhowhy OP @bramblex 或许你可以先解答一下我的疑惑， callback 与 coroutine + channel 比，有何优势？
|
 |
85
CRVV 2016-04-03 19:25:54 +08:00
|
|
86
dphdjy 2016-04-03 19:29:19 +08:00 1
@xhowhy 既然确定 nodejs 没有优势，那就说明你所在的领域用不上，那就没什么可是说的了... 学好要用的就好，语言本身就是工具，问题在于环境和开发者本身，举个例子
> 如果你不相信我，可以看看这个叫“ Bocker ”的项目，它只用了 100 行 shell script ，就实现了 Docker 最重要的功能。 说白了， Docker 的原理就是建立一些目录，把系统文件和相关库代码拷贝进去，然后 chroot ，这样你的代码在里面运行的时候，就以为自己独占一个 Linux 系统。 Shell 语言之恶劣，我已经有专文介绍，所以就不多说了。本来可以用 shell 脚本实现的项目，现在有人用 Go 来做，能说明 Go 是一个好的语言吗？ EOF |
 |
87
chai2010 2016-04-03 19:34:31 +08:00
@xhowhy github 挂了影响也不是致命的，只要本地有一份，或者直接解析 import path 的协议，
或者是 vendor 包含 1 份（ url 只是一个 import path ， github 挂掉并补影响 gopath 的工作，最多时影响 Go get 而已）。 中心话的问题是，某个被大量使用的包稍微做个邪恶的改动就会导致整个社区挂掉（参考前几天 npm 的事故）。 vendor 虽然对版本没那么友好，但是可以完全隔离依赖包改动对当前包的影响。 |
|
88
xhowhy OP @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() 顿时黯然失色。。身不由己被宇宙的黑洞吸进去了，粉身碎骨 |
|
89
xhowhy OP @chai2010 其实 vendor 目前的功能在加载多版本上已经够用了，是 npm 把大家都惯坏了，没有回归到库版本管理的本质。。看来我要收回我刚才在 82 楼说的话。。
在 iOS 开发中 Carthage 就是一个新的去中心化的方案，现在比 Cocoapods 更被社区推崇的原因相信也是如此啊。。 期待 Go 1.6 正式开始 vendor 。。 |
 |
90
lichun 2016-04-03 19:45:55 +08:00
你和他谈笑风生？
|
 |
91
flynngao 2016-04-03 19:50:39 +08:00
go 的包管理太差了实在是
|
 |
93
qiu0130 2016-04-03 19:54:52 +08:00
go logo 受不了。。。
|
 |
94
gamexg 2016-04-03 19:56:52 +08:00 via Android
go 的确好用，静态类型编译时就查出来大部分问题。
python 动态类型后期维护比较痛苦。 go 包管理倒是还没碰到问题，见过通过 url 来控制版本的。 |
|
95
xhowhy OP @gamexg node.js ES6 以后也支持静态类型了， eslint 可以做静态检测，上兼容 es6 的 TypeScript 也行。。
|
 |
96
china521 2016-04-03 20:14:41 +08:00
只喜欢 Go/Java/C++ 这样的静态编译语言，语法提示，那叫一个爽, 其它的动态语言，从来没敢用在实际项目上过....只做为脚本语言来用来提高效率
|
 |
97
lightening 2016-04-03 20:21:23 +08:00
完全没有版本控制，有人提交一个不兼容的改变就全毁了……
|
|
98
loading 2016-04-03 20:46:57 +08:00 via Android
楼主，不要变成嘴炮…
|
|
100
loading 2016-04-03 21:06:21 +08:00 via Android
|
Select Language