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

*难度高不了多少

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

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

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

@dilu F#: 骂谁丑 b 呢

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

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

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

Go 太好了，真开箱即用

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

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

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

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

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

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

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

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

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

go 天下第一好用

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

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

rust 大法好

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

@jlak

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

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

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

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

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

@yu1miao

我觉得差强人意

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

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

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

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

依然被喷.

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

@jianchang512 竟然有点道理

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

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

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

@yu1miao philip wadler 伟大 无需多言

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


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

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

写命令行程序不二的选择

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

soyo （即答

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

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

因为它简单

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

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

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

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

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

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

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 占主流也没什么奇怪的

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

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

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

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

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

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

@emSaVya #58

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


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

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

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

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

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

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

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

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

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

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

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

@emSaVya #7

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

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

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

刚看到的

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

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

result, err := foo()

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

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

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

go 的语法太怪异

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

@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)
}

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

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

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

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

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

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