Go 语言真的有这么破烂不堪吗

[jlak]

前言：
第一次认识 Go 在十几年前了，当时玩着 Python
从那时候印象（没看过代码）里就一直非常好
感觉速度又快又简单
直到最近才开始上手，体验是简单到超乎我的意料
然后感觉深刻的错误判断非常非常的繁琐
几乎每个函数里需要写多个 err!=nil
对于我这种只会写写简单代码的 err!nil 有时超过业务逻辑
但这好处也很大 几乎将所有错误都归到了可视范围

正题：
自从开始正式关注之后，知乎 App 就开始推送大量的 Go 问题的回答（我没有在知乎上关注，应该是根据大数据）
其中绝大部分都是喷 Go 的
而且这个量非常的大 每天都会收到多篇
范围涵盖了 Go 的方方面面
这个量远远超过了我同样关注的 JS/Node
一开始不当回事 但是每天这么多推送
不禁让人重视这个问题

[pfffs]

Golang 伟大，无需多言

[dyllen]

能赚钱就行，管那么多搞屁。

[xiaozhisoc]

只能说设计就是这样设计的吧，说实话 golang 的极简风格导致我每次取变量名都要犹豫好久......

[KaynW]

自己觉得好用就行，不用管别人评价。别人评价特别好也不会直接给你写代码

[sagaxu]

Go 的理念很好，标准库也很好，但语法层面，跟时期出来的语言相比，是差点儿意思，但胜在简单，很少遇到让人惊讶的写法

[dilu]

这么说吧，一个语言或者框架越是被骂/被喷，说明它越火

那些凉透的语言，根本没人在乎

就像都说红颜薄命，实际上是因为没人在意丑 b 活多久

[emSaVya]

嫌 err nil 繁琐的我确实不理解。你写哪个语言函数调用不判断 err 啊？

[joyoyao]

每个语言都有人骂，java 也破烂不堪，连个协程都不支持，大家都开始用 kotlin 。python 也破烂不懒，python2 和 python3 差异太大，运行速度还慢。javascript 更恶心，各种兼容包，还要搞 typescript 。

[LieEar]

我觉得最爽的是二进制部署，docker 包 10MB

[yazinnnn0]

scheme/racket 巨牛逼, 有人用吗?

go 再破烂不堪, 能让你挣钱不就得了

[git00ll]

用来开发小工具超棒，体积小、占用内存小、支持平台多

[wweerrgtc]

十几年前就认识 Go, 这么早

[wktline]

那就用 nodejs 吧，小服务完全覆盖

[lasuar]

这标题，这内容，是会发帖的，学到了。

[cmdOptionKana]

很正常，这与懂车帝就很像，每个车圈里面都骂声一片。其实人性就是如此，喜欢骂一骂，热度热高越招骂。

[henix]

喷的人越多说明用的人越多，真正没人用的语言没人关注
任何编程语言都有优点和缺点，都是取舍，看应用场景选择就好
知乎的推荐机制挺奇怪的，容易产生信息茧房，一部分人慢慢就不发言了。不如多关注几个平台，例如微信公众号、掘金

[NathanCyberC]

用过了就知道 Go 有多爽了，关注业务代码，几乎没有任何糟心事，能够跟它比的就是 Rust 了，但是 Rust 写起来还是比 go 费劲。

[CodeCodeStudy]

java 也要判断 != null 的，别的语言也类似，反正就是调用函数的时候都需要对返回值检查一遍

[Ipsum]

go 一眼看过去就知道干嘛。java 没注释，我都不知道他想干嘛。

[jlak]

我目前用下来这真的很喜欢 Go ，满足我了大部分需求
*编译型
*跨平台
*快速开发
*速度快
*并发

我想要用来代替 Python
虽然开发速度赶不上
但难度目前来看真高了多少

[jlak]

*难度高不了多少

少了一个关键字，没编辑按钮…

[DefoliationM]

学 rust 吧，现在学 go 是 49 年入国军。

[hatch]

难用都别用，让我独享“经验”

[yb2313]

@dilu F#: 骂谁丑 b 呢

[xuld]

大家都喜欢烂东西。毕竟真正优秀的东西是没人喷的，毕竟没人用，怎么喷。

[byboy]

“Go 语言真的有这么破烂不堪吗”这个标题很有知乎味，我认为这种问题不应该出现在这里。希望这里不要像知乎一样。

[neoblackcap]

遇到需要 CGO 编译的东西你就笑不出来了

[trzzzz]

Go 太好了，真开箱即用

[kenvix]

@emSaVya #7 😅有异常的语言还真不判断。判断只在外层合理的时机才执行，甚至还可以外包给框架去判断
当然你说你是 C 语言爱好者当我没说😅

[james122333]

go 基本上还不错 当然有痛点 那就是动态性不太佳 反射也不太好用 毕竟 go 有指标 指标配上反射巨难写 外加范型整个有种很烦的感觉 但为了方便以后弄只好硬写 说到范型只能说 go 目前的是仅堪用 写法有点局限 除了原始函数其它函数加范型牵一髮动全身

[Ricebucket]

这个“破烂不堪”的结论是咋得出来的，你别告诉我就是因为 err😆

[james122333]

当然以麻烦程度 rust 最高
java 则是写一般的超麻烦 写反射倒是还可以

[hefish]

拿着千元的工资，操的万元的心。

[jlak]

@Ricebucket 不是，上面说了 Go 在知乎上几乎方方面面被骂
我没有一一列出来，因为讨论范围会太广
举个小例子（仅列出 无个人观点）给我推送的一些回答是关于
[]作为泛型符号
速度不如 C#
协程还不如 java 虚拟线程
缺少很多内置功能
没有好的 ORM
GIN 性能差
关于 map 什么的我忘了
作者系统语言是大牛 但写 Go 就是草台班子
等等根本列不完

[jlak]

@hefish 我是业余/爱好者，0 元工资😹

[jlak]

我对 Go 如前言里说的印象一直很好
直到上手后更是喜欢
所以不太理解为什么会被喷的这么惨

[guanzhangzhang]

我写了几个小工具放路由器上，基于 adb 库控制手机

[lhasa]

go 天下第一好用

[yanyao233]

没人用的语言没人骂
只要有人用就一定会被骂

如果一个语言能满足所有人需求，就不会有现在的百花齐放了

[BBCCBB]

rust 大法好

[dobelee]

这么多年，喷来喷去就是 err 和泛型，我都看腻了。请换点新花样。😅

[james122333]

@jlak

[]泛型还可以
协程 go 的最方便
运行效率部份很多时候只是标准库实现的并不高效而已 而 gin 刚好就用标准库的
orm 可以自写 map 只有一个痛点那就是 for each 的时后键值要自己排序否则乱序 其实也还好

[james122333]

运行效率再举例 很多人范例和人很爱用 fmt 包 其实这包做了很多其它事 也透过实时反射比较低效方式 明明有时候只是要列印出字串
这时候直接用 println()会是更好的选择

[duluosheng]

Go 语言本身很简练，生态在慢慢丰富。

[james122333]

我还是觉得 go 应该要有第三方标准库

[yu1miao]

Go 泛型从 2010 年 6 月到最终落地足足有四五个不同的实现版本。
早期版本引入新关键字 contract ，直到 2020 年官方宣布放弃 contract 而采用 interface 关键字来实现（也就是 FGG/FG 方案）。
顺带一提，FGG 方案的作者，也是 Java 泛型的作者🤣
interface 方案相比 contract 进行了大幅简化。除了 interface 定义，几乎没有引入什么新语法，对 caller (client) 来说完全无感、也不需要修改任何代码（编译器自动完成类型推断）；
而且所有泛型都会在 编译期 被消除，实现了极致的向下兼容。
单说泛型这块，实在没什么可嫌弃的

[james122333]

@yu1miao

我觉得差强人意

[mengzhuo]

Rust 就一点……编译太 TM 慢了，经常要 5 分钟以上……我这还是 16 核服务器 128G 内存啊，开发板上更慢了，1 小时打底……

Go 能基本能写完就编译好，然后开始跑测试，实验
泛型，老子写业务代码基本不用，麻烦，不如 interface 方便。
库作者自己头疼并折腾去。

[Mandelo]

一个工具，天天被喷烂，还没被淘汰
说明它其他方面很优秀
不懂 go 的路过~

[chaleaochexist]

我学啥 啥被喷
学 python 说 动态语言一时爽, 代码重构火葬场

现在不做 python 了做 go 还不行吗?

依然被喷.

[jianchang512]

Go 的最大缺点是学习曲线不够陡峭，导致太容易入门，逼感不够(doge

[greenhandlwh]

@jianchang512 竟然有点道理

[weiwenhao]

有一些语法诟病但瑕不掩瑜，golang 拥有顶级的跨平台编译，垃圾回收，协程, 兼容性。

[jackmod]

书写简洁，自动管理内存，静态链接机器码，vendor 锁死版本依赖。
真没有几个比 golang 还要紧致的了。

[leonlx]

好像是 C ＋＋之父说的吧，世界上只有两种语言：没人用的和广受诟病的

[Leviathann]

@yu1miao philip wadler 伟大 无需多言

[Trim21]

我是不明白为什么有人反对 go 的泛型用中括号的。难道之前没用过 map 用吗？


@yu1miao 有个槽点是接口泛型可能会导致调用接口的时候变慢…

[emSaVya]

@kenvix 异常不就是处理错误的机制吗？外层不就是在调用处判断吗？这跟 if err 有啥本质区别？难道说就要积累几层调用链 不管是 CE 还是 Runtime Error 都堆到一个地方处理？我不确定这样写的能过 cr 。

[laohucai]

写命令行程序不二的选择

[jaynsw]

系统开发的不喜欢它有虚拟机 再就是异步调用被 gorouting 抽象掉了 没法利用系统调用优化 在应用开发领域 个人觉得 node js 更优 语法也更强大

[CynicalRose]

soyo （即答

[wssy001]

google 的技能树全点在如何提升 AOT 编译速度上了，当初创造 golang 不就是为了加快项目编译
golang 只是 C 的网络语法糖，C 不擅长的，golang 也不擅长

[yangzzz]

@Ipsum 哈哈哈，我最近在接触 python 的 django 框架。去 github 上拉了一个别人写的项目，里面很多东西真的不写注释我也看不懂

[voidmnwzp]

因为它简单

[layxy]

Go 语言胜在语法简单,没太多的语法糖,你可以去看一些开源代码,基本没啥难度,其实 error 没问题,只是习惯了别的语言,需要适应下

[me1onsoda]

用 go 来刷题，有个明显的不爽，二维矩阵没法一步到位声明初始化

[label]

为什么 java 在鄙视链最底端, 被所有其它语言开发者鄙视

[nxcdJaNnmyF9O90X]

语言的趋势 肯定是大道至简 go 这种绝对是未来趋势 反而 java 这种又臭又长的裹脚布 终会被历史抛弃

[securityCoding]

人云亦云，先多写几个项目再说吧，等组织架构变动时隔壁组交接扔过来 100 多 c++微服务你就知道老实人的好了

[panxi]

因为 go 的设计哲学就是显示性和简单性, 比如在 go 中没有类似 python 的 in 操作的语法糖, 你得遍历 orz

[artiga033]

go 的错误处理 我记得官方当年自己推 go2 草案的时候都想过要解决这个问题，一堆人还搁那洗 不过也只是草案罢了 后来也没实现，他哪怕学一下 Swift 的`try?`或者 Rust 的`?`来替换下那几乎每个函数调用后面都有再占三行甚至四行的 if err return 呢

泛型完全不好用，很多时候同样的情况放 C# Rust 都是能自动推导的，比如我初始化结构体调用另一个 New 函数作为初始化字段，我这个字段都是显式泛型类型了，那个泛型函数的类型居然还要我再写一遍？

元编程能力全靠代码生成，难用的一 b ，当然这点其他语言也没好到哪里去

多返回值并非好设计，一旦哪个函数返回多个值那你的链式调用或者嵌套调用就不得不断，当然要是认为这变相保证了代码可维护性也不是不行...

不知道有没有人用过 golang 的 MongoDB ，只要对比一下就能发现 golang 的 map 和 slice 语法到底有多啰嗦

不过要说和 java php 比，那我肯定选 golang ，但是要是吹 golang 语法简单就怎么怎么着的，那我的评价是 go 就是个多了强大的标准库和语言级协程支持的 C 语言罢了

不过云原生时代需要容器体积相对小，又完全自包含的应用，go 确实是不二之选，其他语言要么像 python nodejs 镜像体积太大太乱，要么像 java C#都还在摸索 aot 编译的路上，Rust 入门难度又是地狱级的，golang 占主流也没什么奇怪的

[p1gd0g]

就全栈 crud boy 来说，没重载，没 linq ，没 partial ，有循环引用问题。同样的业务一定是 c# 更快，重构更方便。
当然和 c# 去比本身也不公平

[noyidoit]

@neoblackcap 所以我现在会绕开所有使用 CGO 的东西，比如 mattn/go-sqlite3

[zacard]

挺喜欢 go 的，很多 agent 类的项目都用 go 写的

[InkStone]

错误处理这块，带完备 checked exception （意思是 Java 这种就别来碰瓷了）的异常机制，或者 Rust 这种 sum type 支持的 Result ，都比 Go 的错误处理要舒服很多。

Go 的错误处理机制其实就是 C 的特化版，稍微调和了一下 C 的错误处理与返回值的矛盾，但也仅此而已了。

[gowk]

Go 好是好，但是写业务的时候总感觉哪里不对，想问大家，用 Go 写业务的体验如何
有没有什么最佳实践之类的

[Rache1]

@emSaVya #58

当调用层级越深，这东西越恶心，在我个人看来，方法内部调用链是不是有错误，交给最上层来决定就好了，除非你关心它，没必要一层层传出去。错误这种东西，大部分时候抛出了就说明进行不下去，无可恢复了，如果其中的某一层认为它可以恢复到预期，它就可以捕获了，然后返回正确的结果出去就好了。


比如 A->B->C->D->E 这种调用链，E 出了错误，其实完全可以由他的最上层（ A ）来处理就好了，甚至都可以留给全局异常兜底，没必要在每一次都写一下 if...err 。

[yu1miao]

@Trim21
不应该啊，Go 不允许运行时泛型，编译器会把泛型翻译成普通的类型。

以「泛型函数」为例，处理分为 2 步：
1. 具化（ instantiation ）：根据泛型函数的具体实参，以泛型函数 func foo[P T](param P) 为基础，生成一个不带泛型的普通函数 func foo(param int64) 这里假设传入实参类型为 int64 。然后将该调用绑定到生成的函数
2. 调用（ invocation ）：调用生成的普通函数

按理说，几乎不会有性能差别。

[duty]

@neoblackcap #27 我忘了哪个大佬说的了，“CGO 不是 GO”

[vczyh]

Go 写业务不是很爽，但是有 IDE 的话也能凑合，Go 最适合中间件和 CLI 这种东西，推荐下自己写的： https://github.com/vczyh/redis-lib

[gongquanlin]

除了写 interface 继承做策略工厂的时候比较麻烦，其他的写业务时候还能容忍
但是编译速度快 + 运行成本小 + 部署无需纠结环境 让我容忍了 go 所有的缺点，哈哈~

[losephsky]

唔，再早之前不是一堆人各种夸 golang 吗？

[LanLiang]

挺好的，说明用的人更多了

[HappyAndSmile]

10 多年前就认识？不太相信

[jadeborner]

go 已经不错了，还搁这挑三拣四的

[uiosun]

@emSaVya #7

- try ... catch 直接包裹住问题，不判断
- 对值的合法性进行判断

当初一直这样写，很简洁。

初转 go 的时候，最难接受的就是 120 行代码，15 个 err != nil 判断……属实有点多了，那会儿最希望的是：你直接 panic 吧，别抛给我了 orz

[wysnxzm]

刚看到的

[assassing]

@Rache1 在 Python 中统一错误处理写习惯了，这是我学习 Go 中最不习惯的地方。本意是让开发根据不同错误，就地给出不同解决恢复方案，但这与保持简单相悖。能写出恢复方法就能写出预防方法，防止异常发生。其他情况，同样只能打个日志干瞪眼。

[hez2010]

Go 的错误处理繁琐是一回事，更重要的是设计从根本上就是错误的。

result, err := foo()

一个函数是否发生错误只可能有两种情况，要么发生错误没有结果，要么不发生错误有结果。而 go 的设计直接给你来了个有无结果和有无错误的迪卡尔积，搞出来 4 种情况。
再有，如果你不去手动判断 err 是否为 nil ，则这个可能发生的错误就会直接被无时掉，意味着 go 的错误模型是默认无视掉所有错误。
这种用于错误处理设计不管出现在哪个语言里都是逆天的存在，与其说是错误处理，不如说它就是返回了个 tuple ，而实际上并不存在任何的错误处理机制。

[Jinnrry]

go 哪里破败不堪了？
1 、交叉编译，在座各位有能打的吗
2 、部署体验
3 、没有乱七八糟的包，没有各种语法糖，这是非常大的优点。给你一个上万行的 java 、python 、c++代码的项目，经过几十人接手，每人用着奇奇怪怪的语法糖简写，你看看你能看懂几行
4 、真要破败不堪，battmd 全都大面积在拿 go 写业务，这么多大公司都有病吗

[BinaryDH]

@wweerrgtc 十几年前认识 Go 这个单词而已

[jlkm2010]

go 的语法太怪异

[Tsunayoshi]

金斧头还是铁斧头。。能赚钱就得了

[james122333]

@hez2010

这叫多返回值 能返回的不只两个 其优点是避免了过多的结构嵌套 因为不是所有东西都值得写一个新的结构去包裹
重要的东西写结构更好 只是通常第二返回值为错误

错误处理方式当然直接中断是方便的 但中断本身消耗的资源就多一些 而且你不会知道什么时候会抛错 有些错误是不需要中断的这时候抛错的缺点就跑出来了 需要外部包裹捕获错误的代码 而且 go 并没有缺少中断抛错的方式 所以反而更好

近期我发现一种写法可能更好 那就是写个函数里头判断是否为 nil 不为则 panic 配上 go 里头强大的 import 很好用
go 的 import 具有普通 import 、import as 、import 仅作为依赖、import 至当前命名空间
比 java 的不知道好多少倍 不用写包全名 不用因命名空间让代码不够整洁
如下
package Panic

func PanicIfErr(err error) {
if err != nil {
panic(err)
}
}
=================================
package main

import (
"strconv"
. "example.org/panic"
)

func main() {
a := "123"
i, err := strconv.Atoi(a)
PanicIfErr(err)
println(i)
}

[Trim21]

@yu1miao #78 go 的泛型在面对接口的时候不是这么处理的，可以跑一下这个 bench 试试。这里的 BenchmarkExtra 多了一次接口虚表查询。

https://go.dev/play/p/jMm3oAbaLX0

[gongym]

只有两种语言，一种很多人骂，一种没人骂。
有人骂代表有人用，骂的人越多证明用的人越多。
再说了，从自己的需求出发，适合用什么语言就用什么语言。这年头还有不是全栈工程师的程序员嘛

[geminikingfall]

能用就好，其实除了范型太难看，其他倒没啥太大问题。

[lix7]

其实还好，写习惯了都差不多

[dreamrover]

我是曾经的 go 吹，现在的 go 黑，go 的各种限制太死了，玩了一圈感觉还是 C++香，自己写小东西用 nodejs 更爽，javascript 语法基本照抄 C ，特别灵活，库也特别多。

[yu1miao]

@Trim21 #95
`var buf = &Buffer{}` 拿的是结构体，
`var buf IBuffer = &Buffer{}` 拿的是接口，多一次虚表查询看上去是「接口调用绑定」带来的，感觉跟泛型无关