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

2016 年 4 月 3 日
 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 ?

56764 次点击
所在节点    Node.js
197 条回复
nareix
2016 年 4 月 4 日
@jjx 硬要写当然能写,但时间精力耗费怎么算
hooluupog
2016 年 4 月 4 日
@nareix 写问题不大,最麻烦的是重构。
shyling
2016 年 4 月 4 日
@hooluupog
哦。。第一次我刚刚是想说 if err!=nil 的。。怎么写了个 defer 。。 defer 是个挺有意思的设计,虽然很有可能被到处用。不过 defer 和 RAII 没什么联系吧? defer 充当一个 func 的"析构"可以理解。
说 new 的我觉得有点莫名其妙。很多语言省略了书写不代表否认了 new 的过程。另外我问的是 a:=struct_name{}和 b:=&struct_name{}有什么实际意义上的区别,为什么要这么设计
map[string]string 这里就更奇怪了。我问的是为什么标准库的 map 可以用这样的语法,我自己却不能在我的 UserDefined 里提供这样的语法。这是为什么?
最后呢。。又是常见的问题啦,什么是系统编程语言,和 OO 有矛盾么,你前面说的 new 那部分又是什么呢, Reader.Size()又是什么语法呢?
一个语言的一致性是很重要的。
WildCat
2016 年 4 月 4 日
@hooluupog 说的挺好。

不过 The Go Programming Language 里面说 slice 、 map 都是 reference type 啊
plqws
2016 年 4 月 4 日
第一次看到 Node.js 节点的帖子上热门榜 hhhhh
我又回来了,关于服务端领域的,我认为 Go 还是比不上 Node , Go 其实本身就已经在走下坡路了,发展速度还不如 JS 的一个分支语言 TypeScript ,就只是因为靠 Docker 续了一命,让这个「语法糟糕,代码丑陋」(主观)的语言重新被人们所重视了…
但是我还是认为 Go 还是会继续不温不火慢慢萎靡下去, Go 我感觉很多人更是拿它当做脚本语言在用…和 Go 并肩的项目一般都是 Python 、 Node 之类的语言, Go 想要蚕食这份市场是不可能的,毕竟 Go 本身的 Native 属性在服务端开发领域的 Debuff 让它有一定的学习门槛, Godoc 之类看起来很不错的功能,仅仅是看起来不错而已,真正用起来会发现「这特么是什么二比设计」…甚至有的库作者认为有了 Godoc 就可以不用写文档了,突然想起来前阵子有一群人批判 JavaScript 程序员这样子那样子,现在想想,真的是呵呵呵呵。
songjiaxin2008
2016 年 4 月 4 日
Go 就是缺少好用的 ORM...
jjx
2016 年 4 月 4 日
@hooluupog @nareix

你们可以说动态语言(我这里主要指 python)做大项目需要对程序员有较高的能力. 因为 python 之类的, 如果不用 django 这样的框架的话, 其项目架构其实是没有强制要求. 这就要求开发者较好的架构能力. 但不能说不能写大于 5k 行的代码, 我这里就不拿我自己的项目举例子了. 好的软件就是东西应该在他本来所在的位置, 做到了这点,就能快速定位并解决, 这同语言无关, 同程序的结构组织有关系, 说白了同开发者有关. 当然, java 通过一些框架和模式了强制开发者去遵守这点, 在用动态语言开发时, 语言和框架通常没有约束, 但不能说开发者会不运用这种能力. 说白了, 用动态语言就会写出不能维护的程序的程序员,本身就是上不了台面的.

其次, 重构, 说白了就是查找替换, 没有工具就不能重构这话肯定不对

动态语言的确会有打错变量名的情况出现, 但这些都是冒烟测试可能解决的, 即运行一下测试程序都能暴露出来的, 其次上大部分问题 linter 程序都能自动识别的. 最头疼的错误是逻辑或误写变量之类的导致数据错误, 这类, 动态语言和编译型语言都必须靠测试解决. 编译型语言没有优势


另外, 我觉得同动态语言不能上 5k 的人沟通实际是有问题, 这不是攻击,是你们对工具依赖的太重, 无法信任人本身的自制和能力, 这两种思维估计很难协调一致.
seaify
2016 年 4 月 4 日
翻完了,我大 ruby 木有参战
zkd8907
2016 年 4 月 4 日
路过,围观。 php 是最好的语言!
88250
2016 年 4 月 4 日
hooluupog
2016 年 4 月 4 日
@shyling 可以用来释放资源的(所以说它和 RAII 有相似的地方)。比如打开文件后面要关闭文件。
:= struct{}和:= &struct{}, 一个是值拷贝一个是指针拷贝(如果你觉得拗口,就暂时按引用类型理解, slice , map 这些都可以这么理解),因为有的 struct 可能会非常大,所以为了减少开销,返回一个指针(或者就叫引用吧)。
n := &struct{}和 n := new(struct)是一样的。
的确,省略 new 没省略这个过程,但代码的可读性和连贯性上会大打折扣。 reactive 风格的编程更靠近 FP 语言,在这点上,其实 javascript 比 java 做的要好(JS 比 java 更 FP 一点)。我有个大胆的猜想(java 某一天也会去掉 new ?)
user definded 类型确实不支持,其实这就是不支持泛型的问题。
一切皆 OO 的语言几乎都没有指针,而且默认是按引用传递,而系统编程语言比如(c/c++,算半个系统编程语言的 Go)都是按值传递多一点。这也就造成了很多的不同。比如你可以"string".Replace , python 里面你可以直接各种精度的整数相加,因为这些都是一个 int 对象,而不是具体的值类型,是有抽象在里面的。不能说说谁好谁坏,根据不同的使用场景各有自己的优劣,比如做 application 层面的开发, OO 这种引用类型的使用的多一些,而系统编程语言后者多一些,为了性能以及内存开销低一些,比如游戏开发里面甚至会有专门的值类型,比如支持 SIMD 数值类型。
Reader 是一个接口, size()是实现了 Reader 接口的一个方法。 Go 的接口是非侵入式的,组合起来非常自由,但也有很多人吐槽的,不知道谁实现了谁的问题。

@WildCat 非要按照引用类型的本义去理解(比如 c++里的那种),那么 Go 是没有引用类型的,只是 js/python/ruby/java/php 的程序员都不使用指针,都习惯了引用类型,所以 Go 的 map , slice 那些叫引用类型也成。
但 Go 是按值传递,这点和它们有很大的不同,和 c++更接近。比如 c#是两者都支持(有 struct),但却更接近 java/python 。。。这些。

Go 是续命还是萎靡我不做预测,但拿语法丑陋,缺少一大堆特性来说事,我只能说:你到现在还没搞懂: Go 为何会有人在用它。而这篇文章的作者显然是给出了用 Go 的比较靠谱的理由。
docker 再火其实对 Go 本身影响不大,因为大家都在用 docker(各种语言都支持),而不是用 Go 语言其重写一个又一个新的 docker 。而 Go 自身真正吸引一部分人去用它编程的,不是 docker ,而是服务端开发。

最后: Go 现阶段不要盲目的入坑(写些自己的小项目,小工具除外), Go 其实不太适合新手。 Go 作出的一些语法特性上的牺牲和一些妥协只有在工程上,具体项目上能体会到,撞了墙之后才能有深刻体会。不要被 Go 的语法简洁,上手快等等特点给误导。也就是说:不用只看其一面。

希望这不是引战贴,而是解惑贴,各取所需就行了。
hooluupog
2016 年 4 月 4 日
@jjx 我没说不能,我只说很麻烦。工具让人变懒是好事,希望有更多这样的工具出现,其实包管理的问题也可以,也应该给通过工具去解决,这种脏活,累活本身就是计算机发明出来该替人做的事,不应该把人的精力和兴趣耗在这些琐碎的事情上。
很高兴的看到,这几年无论是动态语言还是前端,也开始重视静态类型以及工具的作用了。
hucsmn
2016 年 4 月 4 日
用 Go 语言有一段时间了,想说说自己对这门语言的感受。
个人感觉用 Go 最大的好处是包管理、测试、部署、代码组织、代码格式化这些杂七杂八的活儿都被同一套规范暴力而又统一地解决了。这样,程序员可以更侧重于去处理代码逻辑,而不是去操心代码怎么缩进这类细枝末节。另外 Go 的那一套标准库、编译速度以及低学习成本也是它的优势。
Go 的坑主要集中在语言本身对一些机制缺乏支持上,比如泛型,官方自己也承认这一点。还有一些功能在设计的时候也比较欠考虑,比如前面 V 友提到的包管理的版本问题。为了弥补这些问题, Go 后续又搞出了 vendor 、 generate 这些功能很有限的机制。它们虽然能用,但是明显满足不了人们的期待。
目前我主要用 Go 写一些跑在 Linux 服务器上的工具,所以上面这些坑对我来说一般也遇不到,算下来我觉得多学这么一门语言还是非常值得的。
xhowhy
2016 年 4 月 4 日
@hooluupog 感谢,正面解释了 Go 的很多细节,比我高得不知道多少去了。
@nareix 动态类型和并发编程是 node.js 服务端编程上一直存在的短板,所以才一直在改善,有了 ES6 ,有了 TypeScript ;开发框架也从 express.js 到 koa ,异步编程工具从 async.js 到 co 再到 Promise ,都是为了解决这些问题。
包管理 npm2 到 npm3 也发生了巨大变化,也是为了解决多版本管理的问题。
写过三年的 node.js 服务端代码,所以在看到 Go 的时候,难免会这么想:如果一开始就用 Go 来写,是不是就可以避开 node.js 服务端编程中那些不成熟的坑,不用频繁地切换框架、工具,不用改变编程习惯,不用频繁重构,更高效地编程,把时间完全投入到业务逻辑上而不用各种入坑填坑。
毫无疑问 node.js 生态还是屌屌的,工作中仍会继续使用,也相信坑总有一天坑会填完;也会在个人项目中开始尝试 Go ,体会一下另一种坑的滋味。
RRL
2016 年 4 月 4 日
并不喜欢 Go 但是 rust 很不错的样子
aphasia
2016 年 4 月 4 日
@nareix 在理,动态语言在大规模项目开发容易,多个版本迭代下来,维护起来好麻烦的
ototsuyume
2016 年 4 月 4 日
Golang 跟 node.js 的应用场景没多少交集,根本不能直接比较。就拿 Golang 的那些开源项目来看, group cache/docker/Kubernetes/tidb ,这些项目该怎么用 js 来写?语法特性是否优美丰富从来就不是 Golang 的卖点,它最大的卖点是简单没有复杂的语法特性甚至还强迫你们大括号要换行私有变量名要小写,杜绝了各种奇怪难懂的写法,加上丰富易用的工具链,是一种只为实际工程开发做了很多妥协的语言。国内也有不是公司用 Golang 做过线上的服务,比如七牛和领英的赤兔整个后台都是 Golang 写的, bat 也有部分组用 golang 做了不少轻量级的服务,我之前的公司甚至还用 Golang 做了一个类淘宝 TFS 的分布式小文件服务系统和类 hbase 的分布式存储系统。国外 FLAG 乃至 uber/airbnb 都有不少系统是用 Golang 开发的。

另外当年 C/C++在 linux 网络编程里面经常被人垢病的一点就是 linux 多线程性能不高,只能单线程 epoll 配合状态机或者 callback 来写网络服务,导致逻辑支离破碎难以调试,所以 node.js 的 callback 在现在来看是一种倒退。
timothyye
2016 年 4 月 4 日
@xhowhy 不是说 Go 坑,欢迎入坑,是欢迎加入 Gopher 的队列,哈哈
shyling
2016 年 4 月 4 日
@hooluupog 为什么你可以举着 C++的例子把他放到不 OO 那里了啊。。。而且不能++--的指针有什么用=-=
m8syYID5eaas8hF7
2016 年 4 月 4 日
java 程序员默默飘过,全程围观 :)

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://v2ex.ih06.com/t/268296

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX