已获得原公众号的授权转载
之前每次写 Go 错误处理的相关提案时，大家都会在评论区探讨到一个事。
Go 这活不得劲，常被戏称，一个大型 Go 工程项目里 60% 的代码都是 if err != nil。
咱们错误处理怎么不借鉴一下 Rust，高低也整个问号的语法特性，就可以简化这三行了，不香吗？
借鉴 Rust 用 ？！| 符号
核心的点是在现有的 Go 例子中，我们一般要写 if err != nil，多了之后又多又杂看起来还有些麻烦。
如下 Go 代码：
count, err = fd.Write(bytes)
if err != nil {
return nil, err
}
如果我们也借鉴 Rust 使用 ! 和 ？的简化版，我们可以演进为如下代码：
count := fd.Write!(bytes)
count := fd.Write(bytes)!
count := fd.Write(bytes)?
也有大佬提到可以演进一下使用 || 变成：
fd.Write(bytes) || Expr
不管如何，就是不需要写三行的 if err != nil 去处理这个硬逻辑，只要加个符号（类似语法糖）就行，由编译器和运行时自己去处理就完了。
这类提案都会被拒绝
为什么最后 Go 没有落地呢？
普遍社区中参与讨论的大佬认为，新的语法糖相较 if err != nil，会增加认知和理解代码的开销，并降低代码可读性。
这些神奇的的功能和符号，他们是隐秘的，更容易让人错过，会导致程序控制流逻辑发生改变，增加程序员的心智负担。
Go 初学者也需要额外掌握这几个符号的理解和应用，有新的学习成本。
这类提案会被直接拒绝，请大家不要再幻想了。
希望开发者自己定模板
如果只是为了解决那 3 行代码，部分大佬表示 Go 开发者应该自己定义错误模板。而不是借助引入更多的新语法来解决，这也不符合 Go 语言对 “less is more” 的理念定义。
从现在对 Go 错误处理的多个提案讨论和社区交流来看，Go 在这块已经陷入僵局，很像工作中的什么呢？
像我们常提的既要也要还要，重要的是这事 ROI 也不够高，导致Go 核心团队的动力不足，也不想互相得罪了。
只能甩出一句经典：”让 Rust 特性留给 Rust“。
总结
Go 错误处理 if err != nil 的解决，已经成为了一块烫手的山芋，怎么改都不讨好了，相关负责人积极讨论，实施持续摆烂中，没有新的建设。
根据以往在依赖管理的，我猜测最终大概率会由 Go 团队大当家 Russ Cox 操刀，否则很难有人能力挽狂澜。不过，目前来看他对此并不感兴趣。对于开启 Go 工具链遥测的提案，也刚吃了闭门羹。
错误处理的碰撞，真是 Go 的一生之敌。
<END>
程序员专属T恤
商品直购链接