golang, 开发效率低执行效率高的语言?

5 天前
 iintothewind

最近因为偶然的原因, 不得不用了一段时间的 go. 经过这一段时间的使用, 发现这门语言实在是有太多不爽的地方, 所以就在这里吐槽一下, 看看是不是因为我理解不对, 还是这就是 go 语言以及生态的缺陷.

语法表达力非常差

go 的控制流非常简单: for, if, else, switch and defer 就是全部了 当然, 你如果之前对计算机语言所有的认知都来自于命令范式的语言(比如 C), 这并没有什么, 甚至觉得够用了.

但是对于偏函数式风格的语言, 这简直太简陋了, 函数式的控制流不仅有 for, if-else, 对于 switch 来说有更加强大的 pattern-match, 对于 defer 这种玩意, 有更好 try-catch-finally 替代, 而且你想怎么写就怎么写. 而且支持 unit, filter, map, flatMap 等等统一的操作.

golang 控制流的简陋直接造成了 golang 的语法表达能力差. 解决同样的问题, 需要更多更长的代码, 就像当年不支持 Lambda 特性的 Java 一样.

我就奇怪了: Java 没有支持 Lambda 以前, 人人骂 Java 代码啰嗦, 写起来累人, 到了 golang 了这么差的语法表达力, 怎么就成了简单清爽?

简陋敷衍的容错处理(Error Handling)

我接触到其它语言在写后端业务逻辑是, 对于 public 方法的入参是采取完全不信任的态度的. 原因很简单, 传进来的值在运行时存在非常多的可能, 最典型的就是 null 值一定要处理. 如果存在 a.b.c.d 等这样取值方式, 恐怕要不得不采用 Option 一层层去拿. 我可以理解有人说 Option 麻烦, 不管你用什么方式, 至少判空的逻辑是少不了的.

但是, Golang 是没有 Option 和 Try 的, golang 甚至连三元表达式都没有, 所以一般 Golang 是这样做的:

if a == nil { return nil, someError("...") }

b, err := a.b

if(err != nil) { return nil, someError("...") }

后面一大长串的 if(err != nil).......

如果你天天是写这样的代码, 你觉得这叫简洁?

少到寒酸的集合类型以及集合操作

其实 golang 的集合就只有个 array 和 map.

还有人说 array 的 slice 支持操作很方便啊? 我劝你醒醒, 看看其它语言吧, 就这几个操作哪个语言不支持啊?

Go 默认集合类型就是可变的, 所以所有对集合的操作, 实际上是修改集合自身. Go 是没有不可变集合这个概念的.

嗯, 找了找居然有人写了类似于 Linq 的 go-linq, 但是你看看相同的操作, go 得写多少代码吧, 而且每个操作结束时输出的变量居然时实现声明好再传进去的, 连直接输出到一个不可变集合的能力都没有.

蛋疼的数据库处理

其实我认为 Java 的数据库处理已经够老旧了. JDBC 标准已经很久没更新了, 而且很可能也不再更新了, 之前很多人期待的原生异步处理能力很可能不会再有了. Java 比较流行的 ORM 框架, hibernate 和 MyBatis 也已经非常老了, 老到都没办法在多线程环境下正常运行, 因为 Context 默认是单线程环境的. 但就这么老的 ORM 框架, 或许没办法跟.Net 的 linq 处理效率比一比, 但跟 Go 比起来也是好太多了.

来来来, Go 现在访问数据库, 有好的 ORM 框架吗? 有一个 sqlc 代码生成器, 大家已经觉得好太多了, 比自己写实在是快多了, 怎么不骂 Go 的数据库处理低效了, 就这??? 连个像样的 ORM 框架都没有.

鸡肋的泛型系统

Go 有泛型, 但又不支持方法级别的泛型.

Go 也没有泛型型变的概念.

所以你在接口上做一定程度的抽象, 绑定更多操作, 生成新的类型的实例是做不到的.

总结

Golang 其实真的只是一个 Better C 的定位, 当然这还是在开发效率上来说的, 就是仅仅** Better-Than-C **. 但 Golang 这简陋的语法, 相对于其它非常多的现代语言来讲, 还是差的很多的.

可能 Go 语言的那几个掌舵人就是典型的命令范式计算机语言的拥趸, "嗯, 我们可绝不会加入任何函数式的特性, 这会增加这个语言的复杂度, 降低编译速度, 让语言不纯粹...."

您说您的, 但是 Go 写写底层就好了, 毕竟比 C 好. C 可是连数据类型概念都没有, 从来只操作内存的.

现在结构体都允许写接收方法了, 也能写点泛型了, 内存都帮你回收了, 你还想怎样?

什么? 你说用 Go 写业务逻辑很痛苦???

谁让你用 Go 写业务逻辑了, 跟你说了别去跟那帮写 Java 的混一起, 他们就只会 spring, 除了 spring 啥都不会.

15962 次点击
所在节点    程序员
178 条回复
dayeye2006199
5 天前
其实还行。心智负担很小,因为就那么几个语言特性,搞明白了就搞明白了。
iintothewind
5 天前
@gam2046 #20 但是如果从别的拥有更高语法表达力的"现代语言"转过来时, 写复杂逻辑就有一个非常大的落差, 我就经常想, 我靠, 就这点功能, 我要是用 XX 早就几行解决了, 结果 go 这里就只能先这样, 在这样, 在这样, 局部变量一大堆, 内部状态改来改去, 心智负担其实更大.
lasuar
5 天前
@iintothewind rust 我早已学完了。。但想要在项目中采用,还得考虑其他成员的技术 lv 和负担,我无法要求身边的人都跟我一样花费足够多的时间去学习一门系统语言,然后用来写 web 业务。
wwhontheway
5 天前
其实一直不太理解 if err != nil 到底有什么问题?
helone
5 天前
@wwhontheway 有强迫症或者语言洁癖的可能受不了
importmeta
5 天前
服务器用 Go 最省钱, 举个例子,一个后台用 Go 写 6MB, Node 60MB, Java 300MB.
GooMS
5 天前
觉得 err 挺好的,有问题就介入
EscYezi
5 天前
关于错误处理,我认为 go 最大的问题是 error 作为返回值可以不做任何处理继续向下执行,这可能会导致预期外的错误,而且很难排查。哪怕是 java 至少也得手动 catch 一下。
虽然有 linter 能缓解这个问题,但是总感觉很不安全
mogging
5 天前
go 在 devops 工具开发这个领域没什么对手
lloovve
5 天前
那可以学 Rust ,本身主用 c ,过度到 golang 写网络相关的服务,还挺爽的
Ayanokouji
5 天前
@wwhontheway #24 ,if err != nil 最大的问题是这个 err 怎么处理。web 业务通常情况下的逻辑就是一层层往上返回,如果出问题如何进行排查,这里很考验对 err 的处理策略,心智负担还是挺大的。
rekulas
5 天前
骂的很对 但我最喜欢的还是 go , 它的优点完美实现了我的需求这就够了,至于缺点,哪个语言没有呢
wysnxzm
5 天前
不好的就是 feature 是故意这样设计,是你们逼的
好的也是 feature 是故意这样设计,但跟你们无关
kele999
5 天前
太对了,我希望有三元操作符
xingjue
5 天前
java 回去玩 java 喜欢又臭又长的裹脚布的 一辈子也改不了
cccvno1
5 天前
味道太冲了
xiuming
5 天前
go 造它有它的使命,肯定不是为了满足你的要求而设计的。你们技术选型出现问题怪不到语言身上。Google 公司认为它就应该是这样的,就这样没有什么其他原因。Google 没有义务造你想要的,它也不会追求和别语言一样设计,能理解就理解 理解不了也没办法。
tairan2006
5 天前
开发效率其实还好…语法确实很简陋,但是方便理解,有利有弊吧。

增删改查就用 sql builder 直接写啊,orm 这种东西有没有无所谓的。
iintothewind
5 天前
@xingjue #35 我又不是只用一种语言, java, go, c sharp, javascript, typescript, python, scala, haskell, scheme 都用过.
再说了 你说 java 又臭又长可不对啊, java 现在的版本比 go 语法特性可多多了, 相比之下也只能说 golang 代码 "又臭又长" 啊.
sunny352787
5 天前
@kele999 AI 教我 golang 的三元运算这么写:result := map[bool]any{true: "true", false: "false"}[true]

又不是不能用.jpg

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

https://www.v2ex.com/t/1101972

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

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

© 2021 V2EX