最近因为偶然的原因, 不得不用了一段时间的 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 啥都不会.

举报· 4533 次点击
登录 注册 站外分享
43 条回复  
zhaoahui 小成 3 天前
gorm
javalaw2010 小成 3 天前
确实,go 语言问题不少。不过流行的语言几乎都有各自的问题:java/kotlin/python/js/php/C 族/rust, 哪个没被拉出来掉在城门楼上鞭尸过?也有的语言确实看起来各个方面都很不错,缺点嘛就是没人用。 我曾经也想找一门各方面都完美的语言,集各家编程语言之大成,从前端到后端,从 20 块的嵌入式硬件到几千亿美元的空间站,给广大开发者带来无与伦比的开发体验。结果就是陷在语言选择的囹圄里不能自拔,日月蹉跎。 现在想明白了,如果你有技术栈选择权,你就选自己最顺手的语言,你自己的项目,你就爱怎么写就怎么写,大兵团作战,你就多点几下鼠标键盘,把类型提示和目录分层做好;如果你没有技术栈选择权,就老老实实在屎山上拉屎。早点干完活早点回家陪家人,人生苦短,不必在赛博搬砖上浪费人生大好的时光。
lbp0200 小成 3 天前
java 不都是 jsp 吗?需要写非常多的 XML 才是正统啊,spring 是啥?一定是邪教。
iintothewind 楼主 小成 3 天前
@lbp0200 #3 其实在大部分 Non-Java Developer 眼中, 大概率 java 约等于 spring
iintothewind 楼主 小成 3 天前
@javalaw2010 #2 对, 我这阵子用 Go 也是没得选, 只能硬着头皮用, 所以才很想吐槽, 唉....
INCerry 小成 3 天前
似乎执行效率也不高?看各种 benchmark 的结果,go 并不占优势
iyaozhen 小成 3 天前
“语法表达力非常差”这是 feature ,不是 bug ,就是这样设计的,语法糖很少,别人也没说他是函数式编程呀 “人人骂 Java 代码啰嗦, 写起来累人” 骂 java 啰嗦是说面向对象那一套吧,和 Lambda 关系不大 代码并不是越短越好,是越清晰越好。这方面 Lambda 被人诟病很多,特别是 python 还只能写一行,别人根本看不清(当然 ide 可以展开) “Error Handling”这个是老生常谈的问题,golang 这样确实不是最优解,但不代表 try catch 就是最佳实践 “少到寒酸的集合类型以及集合操作” 同第一点,故意设计的 ORM 框架 可以看看 gorm 和其新的 gen 泛型别人 Google 本来也不想做,这不是你们逼的嘛 其实 Go 最大的问题是 Google 一家之言,不接受社区建议。说到底这就是别人自己的语言,他们好用,开源出来而已。 Go 不是不适合写业务,是不适合和 java 比较。你之前用 java 的,用 go 怎么都别扭。go 当然也想和 java 争一下 web 的市场,但被干掉的反而是 php 、node 、python 这些 web 的市场(注意我说的是 web 市场 我之前写 php web 的,我觉得 go 比 php 好很多,性能和工程 2 楼其实说的在理。我个人认为你选语言就像相亲一样,要多看看别人优点,以及最不能忍受的缺点。go 在性能这一块就是好一点,适合微服务部署(当然 java 在一些 jvm 改造后也行,但先入为主的观念很重要)
iyaozhen 小成 3 天前
@iintothewind #5 当然,你没得选就另说了。只能多看看优点吧 毕竟马云让我吃屎,我也能吃穷他
lasuar 小成 3 天前
标准库对于业务来说支持的方法是挺简陋的,现在要需要引入三方库,好在生态已经逐渐完善,有很多库可用。go 对于 java 的优势应该主要是原生协程、编译型语言。也确实没有一个特别好用的 orm 库(现在的 goframe 的 orm 组件还行 >> gorm )。怎么说,要一个开发效率与性能齐驱的语言,目前还是没看到的。 对于 Java ,个人很讨厌其语法上的臃肿。
12345下一页
返回顶部