Golang Go语言真的有这么破烂不堪吗
第一次认识 Go 在十几年前了，当时玩着 Python
从那时候印象（没看过代码）里就一直非常好
感觉速度又快又简单
直到最近才开始上手，体验是简单到超乎我的意料
然后感觉深刻的错误判断非常非常的繁琐
几乎每个函数里需要写多个 err!=nil
对于我这种只会写写简单代码的 err!nil 有时超过业务逻辑
但这好处也很大 几乎将所有错误都归到了可视范围
正题：
自从开始正式关注之后，知乎 App 就开始推送大量的 Go 问题的回答（我没有在知乎上关注，应该是根据大数据）
其中绝大部分都是喷 Go 的
而且这个量非常的大 每天都会收到多篇
范围涵盖了 Go 的方方面面
这个量远远超过了我同样关注的 JS/Node
一开始不当回事 但是每天这么多推送
不禁让人重视这个问题
Golang Go语言真的有这么破烂不堪吗
更多关于Golang Go语言真的有这么破烂不堪吗的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
每个语言都有人骂，java 也破烂不堪，连个协程都不支持，大家都开始用 kotlin 。python 也破烂不懒，python2 和 python3 差异太大，运行速度还慢。javascript 更恶心，各种兼容包，还要搞 typescript 。
喷的人越多说明用的人越多，真正没人用的语言没人关注
任何编程语言都有优点和缺点，都是取舍，看应用场景选择就好
知乎的推荐机制挺奇怪的，容易产生信息茧房，一部分人慢慢就不发言了。不如多关注几个平台，例如微信公众号、掘金
go 基本上还不错 当然有痛点 那就是动态性不太佳 反射也不太好用 毕竟 go 有指标 指标配上反射巨难写 外加范型整个有种很烦的感觉 但为了方便以后弄只好硬写 说到范型只能说 go 目前的是仅堪用 写法有点局限 除了原始函数其它函数加范型牵一髮动全身
不是，上面说了 Go 在知乎上几乎方方面面被骂
我没有一一列出来，因为讨论范围会太广
举个小例子（仅列出 无个人观点）给我推送的一些回答是关于
[]作为泛型符号
速度不如 C#
协程还不如 java 虚拟线程
缺少很多内置功能
没有好的 ORM
GIN 性能差
关于 map 什么的我忘了
作者系统语言是大牛 但写 Go 就是草台班子
等等根本列不完
[]泛型还可以
协程 go 的最方便
运行效率部份很多时候只是标准库实现的并不高效而已 而 gin 刚好就用标准库的
orm 可以自写 map 只有一个痛点那就是 for each 的时后键值要自己排序否则乱序 其实也还好
运行效率再举例 很多人范例和人很爱用 fmt 包 其实这包做了很多其它事 也透过实时反射比较低效方式 明明有时候只是要列印出字串
这时候直接用 println()会是更好的选择
Go 泛型从 2010 年 6 月到最终落地足足有四五个不同的实现版本。
早期版本引入新关键字 contract ，直到 2020 年官方宣布放弃 contract 而采用 interface 关键字来实现（也就是 FGG/FG 方案）。
顺带一提，FGG 方案的作者，也是 Java 泛型的作者🤣
interface 方案相比 contract 进行了大幅简化。除了 interface 定义，几乎没有引入什么新语法，对 caller (client) 来说完全无感、也不需要修改任何代码（编译器自动完成类型推断）；
而且所有泛型都会在 编译期 被消除，实现了极致的向下兼容。
单说泛型这块，实在没什么可嫌弃的
Rust 就一点……编译太 TM 慢了，经常要 5 分钟以上……我这还是 16 核服务器 128G 内存啊，开发板上更慢了，1 小时打底……
Go 能基本能写完就编译好，然后开始跑测试，实验
泛型，老子写业务代码基本不用，麻烦，不如 interface 方便。
库作者自己头疼并折腾去。
异常不就是处理错误的机制吗？外层不就是在调用处判断吗？这跟 if err 有啥本质区别？难道说就要积累几层调用链 不管是 CE 还是 Runtime Error 都堆到一个地方处理？我不确定这样写的能过 cr 。
google 的技能树全点在如何提升 AOT 编译速度上了，当初创造 golang 不就是为了加快项目编译
golang 只是 C 的网络语法糖，C 不擅长的，golang 也不擅长
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 占主流也没什么奇怪的
错误处理这块，带完备 checked exception （意思是 Java 这种就别来碰瓷了）的异常机制，或者 Rust 这种 sum type 支持的 Result ，都比 Go 的错误处理要舒服很多。
Go 的错误处理机制其实就是 C 的特化版，稍微调和了一下 C 的错误处理与返回值的矛盾，但也仅此而已了。
#58 
当调用层级越深，这东西越恶心，在我个人看来，方法内部调用链是不是有错误，交给最上层来决定就好了，除非你关心它，没必要一层层传出去。错误这种东西，大部分时候抛出了就说明进行不下去，无可恢复了，如果其中的某一层认为它可以恢复到预期，它就可以捕获了，然后返回正确的结果出去就好了。
比如 A->B->C->D->E 这种调用链，E 出了错误，其实完全可以由他的最上层（ A ）来处理就好了，甚至都可以留给全局异常兜底，没必要在每一次都写一下 if…err 。
不应该啊，Go 不允许运行时泛型，编译器会把泛型翻译成普通的类型。
以「泛型函数」为例，处理分为 2 步：
1. 具化（ instantiation ）：根据泛型函数的具体实参，以泛型函数 func foo[P T](param P) 为基础，生成一个不带泛型的普通函数 func foo(param int64) 这里假设传入实参类型为 int64 。然后将该调用绑定到生成的函数
2. 调用（ invocation ）：调用生成的普通函数
按理说，几乎不会有性能差别。
Go 写业务不是很爽，但是有 IDE 的话也能凑合，Go 最适合中间件和 CLI 这种东西，推荐下自己写的： https://github.com/vczyh/redis-lib
除了写 interface 继承做策略工厂的时候比较麻烦，其他的写业务时候还能容忍
但是编译速度快 + 运行成本小 + 部署无需纠结环境 让我容忍了 go 所有的缺点，哈哈~
#7
- try … catch 直接包裹住问题，不判断
- 对值的合法性进行判断
当初一直这样写，很简洁。
初转 go 的时候，最难接受的就是 120 行代码，15 个 err != nil 判断……属实有点多了，那会儿最希望的是：你直接 panic 吧，别抛给我了 orz
在 Python 中统一错误处理写习惯了，这是我学习 Go 中最不习惯的地方。本意是让开发根据不同错误，就地给出不同解决恢复方案，但这与保持简单相悖。能写出恢复方法就能写出预防方法，防止异常发生。其他情况，同样只能打个日志干瞪眼。
Go 的错误处理繁琐是一回事，更重要的是设计从根本上就是错误的。
result, err := foo()
一个函数是否发生错误只可能有两种情况，要么发生错误没有结果，要么不发生错误有结果。而 go 的设计直接给你来了个有无结果和有无错误的迪卡尔积，搞出来 4 种情况。
再有，如果你不去手动判断 err 是否为 nil ，则这个可能发生的错误就会直接被无时掉，意味着 go 的错误模型是默认无视掉所有错误。
这种用于错误处理设计不管出现在哪个语言里都是逆天的存在，与其说是错误处理，不如说它就是返回了个 tuple ，而实际上并不存在任何的错误处理机制。
go 哪里破败不堪了？
1 、交叉编译，在座各位有能打的吗
2 、部署体验
3 、没有乱七八糟的包，没有各种语法糖，这是非常大的优点。给你一个上万行的 java 、python 、c++代码的项目，经过几十人接手，每人用着奇奇怪怪的语法糖简写，你看看你能看懂几行
4 、真要破败不堪，battmd 全都大面积在拿 go 写业务，这么多大公司都有病吗
这叫多返回值 能返回的不只两个 其优点是避免了过多的结构嵌套 因为不是所有东西都值得写一个新的结构去包裹
重要的东西写结构更好 只是通常第二返回值为错误
错误处理方式当然直接中断是方便的 但中断本身消耗的资源就多一些 而且你不会知道什么时候会抛错 有些错误是不需要中断的这时候抛错的缺点就跑出来了 需要外部包裹捕获错误的代码 而且 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)
}
#78 go 的泛型在面对接口的时候不是这么处理的，可以跑一下这个 bench 试试。这里的 BenchmarkExtra 多了一次接口虚表查询。
https://go.dev/play/p/jMm3oAbaLX0
只有两种语言，一种很多人骂，一种没人骂。
有人骂代表有人用，骂的人越多证明用的人越多。
再说了，从自己的需求出发，适合用什么语言就用什么语言。这年头还有不是全栈工程师的程序员嘛
我是曾经的 go 吹，现在的 go 黑，go 的各种限制太死了，玩了一圈感觉还是 C++香，自己写小东西用 nodejs 更爽，javascript 语法基本照抄 C ，特别灵活，库也特别多。
#95var buf = &Buffer{} 拿的是结构体，var buf IBuffer = &Buffer{} 拿的是接口，多一次虚表查询看上去是「接口调用绑定」带来的，感觉跟泛型无关
关于Golang（Go语言）是否真的破烂不堪，这样的评价显然过于片面和主观。Go语言作为一种现代编程语言，自其诞生以来，已经在多个领域证明了其价值和实用性。
首先，Go语言以其简洁、高效和强大的并发处理能力而著称。它提供了简洁的语法和丰富的标准库，使得开发者能够快速地编写出高性能的代码。同时，Go语言的并发模型（如goroutines和channels）使得处理并发任务变得简单而直观。
其次，Go语言在社区支持、生态系统以及企业应用方面也有着显著的优势。随着越来越多的企业和开发者选择使用Go语言，其社区规模不断扩大，生态系统也日益完善。这为用户提供了丰富的第三方库和工具，进一步提升了开发效率和代码质量。
当然，任何编程语言都有其不足之处，Go语言也不例外。但是，这些所谓的“破烂不堪”之处往往可以通过学习、实践和社区的帮助得到解决。事实上，Go语言的持续发展和改进正是得益于其开放和活跃的社区。
因此，我们不能简单地因为一些主观的评价就否定Go语言的价值。相反，我们应该客观地看待其优点和不足，并结合自己的需求和场景来选择合适的编程语言。对于对并发处理、性能优化等方面有较高要求的开发者来说，Go语言无疑是一个值得考虑的选择。
