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

8 天前
 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 啥都不会.

16180 次点击
所在节点    程序员
178 条回复
cookgo
7 天前
如果一门语言能方便快速的解决所有的问题,这不是垄断了嘛
Richared
7 天前
@importmeta #26 安卓手机内存都 16g 了,在这纠结服务器省钱? 2c1g 的服务器么?
windyboy
7 天前
如果和数据库交互一定要 ORM 的话,我只能说要么设计数据库的是天才,要么没有接触过真实业务
seansong
7 天前
哈哈,同样的语气,可以用来骂任何语言,目前还找不到完美的语言

年轻人,学会跟自己和解,学会跟语言和解,有些事情不一定非要争一个胜负,我们都是在不断的妥协中争取进步,我们都是在自己的喜好中寻找语言,如果看 go 不顺眼,就下次不用了就行,要不,推荐你来学学我现在主要在用的 rust ?

有时候,多写几行代码不是坏事,或许,理解为更高的 kpi ?
zheng0432
7 天前
go 的理念不就是一切从简吗,try catch finally 不感觉太啰嗦了吗
Biem
7 天前
@roundgis Rust 调研过了,在验证交叉编译 mipsel 目标这关没过。Go 自己造编译器去适配各种 CPU 架构这点在兼容各种嵌入式设备上,Rust 相比还有一段路要走。当然确实最开始在语言选型阶段的时候 Rust 作为编译型的内存安全语言是考虑在内的。
cj323
7 天前
我也不喜欢 go ,很早就试过了但是写着感觉太蠢太啰嗦,一直没有再碰过。我还是喜欢写着爽,自由的语言,比如 JS ,Ruby ,Elixir 。

但我能理解喜欢 go 的人,语言简单稳定,没有太多花哨。我甚至认为 go 开发效率更高,就像 rob pike 的 unix 哲学,大道至简,less is more 。
jeesk
6 天前
一些服务准备迁移到 CF 的 worker 上,serverless 才是王道。

不到 20 个接口, 用 CF worker 太香了。
firstep
6 天前
@xingjue 该说不说,没喷到点上。up 说的问题没有一条跟 Spring 有关,纯粹是语法糖和轮子的丰富程度。Java 并不等于 Spring


@lvlongxiang199 确实啰嗦,面向接口编程跟 Java 没关系,只是在 Java 工程实践滥用了,但是工程实践是可以调整的。
asdfsadfsdf
6 天前
@seansong 爹味太重
james122333
6 天前
所有静态语言含 typescript 都是这样的 都是开发效率低
至于简洁那是因为这个语言杂讯较少 写法工整 少有语法糖扰乱视觉
jackmod
6 天前
前阵子边抄边写 go 弄了个命令行小工具,后来一直没用就把 go 忘光了。
现在在练 rust ,练差不多了重新学 go 。目的是减少对 py 的依赖。
当然,吃饭的吊命玩意依旧是 java ,老舒适区了。
SenLief
6 天前
@zheng0432 那错误处理也是一切从简吗?
Nasei
6 天前
go 比 java 强多了

当然,他们都被 C# 吊起来打

无奈国内公司的工作数量是 java >> GO > C#
DeWjjj
6 天前
本来所有的语句都应该确认是否产生错误,并加以处理。
不然代码函数复合之后,你 debug 跳步都找疯了。
1055619878
6 天前
我用 go-zero 开发 java build 的时间 我已经调试完一个接口了 开发效率提高太多了 根本不是一个级别的
jheroy
6 天前
你说的这些我觉得都是优点,语法糖少说明同一个逻辑不通的人实现是差不多的,而不像其他语言一个人一个写法。另外还有就是编译快,可以完全静态链接,生成一个可执行文件,无任何依赖,不想其他语言要么依赖动态链接库,要么需要装解释器。至于啰嗦问题,现在都是 ai 补全了,重复代码 ai 还是很精准的。
guiyumin
6 天前
@reeco zig 还没有到 1.0
我也想学,但这个会不会将来大改 api ?
kenvix
6 天前
新生代语言( Rust 、Kotin 、Go 等)里面就 golang 这个货最逆天,开时代倒车
kenvix
6 天前
@jheroy #157 “可以完全静态链接,生成一个可执行文件,无任何依赖,不想其他语言要么依赖动态链接库,要么需要装解释器”你说的这些东西和语言能力没半点关系

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

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

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

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

© 2021 V2EX