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

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


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

https://i.imgur.com/rTgI9A2.png

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

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

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