今天在写课程作业的时候，才感慨 Golang 都 2022 年了，还是没有 int 的 max 函数，需要取两个数的较大值的时候还是要到处写自己的 max 函数。
搜索能找到的理由是：Go 不支持函数重载，如果要提供各种类型的 min/max 函数，则要为每一个单独使用一个函数名。为了保持 Go 的简洁（which I find ridiculous...)，所以只提供了 float64 的 min/max 函数。（而同样自带的sort包里却对各种类型都实现了一个函数进行排序，emmmm。实际上这里完全可以再搞一个minmax包之类，把这几十个 min/max 函数放进去）
然而 2202 年了，Go 含有泛型Generic支持的版本 1.18 也正式发布了，依然还是要到处自己写 min/max 函数 😅
于是乎又想起来 Golang 的种种 inconsistency，如 interface{} 类型的参数看似是值传递，但实际上隐式地可以传递指针而不会引发拷贝：
（interface{} 的这个设计导致很多库在接收 interface{} 参数的时候，还需要多加一层反射判断来判断传入的是指针还是值，除了使代码更困惑外还有实际的性能影响，而同时没有什么想得到的好处）
然后搜索 min/max 问题的时候也发现了这么一个网站：https://unexpected-go.com，里面也提到了这个问题：https://unexpected-go.com/theres-no-min-function.html。
这个网站看起来的目标是记录 Golang 的一些比较 unexpected 的行为/习惯，不过现在好像也只有7篇。
话说回来 Golang 的核心维护团队也真的是固执，社区很多年的许多要求和提案核心的几个成员都有直接否决的权利，而且也几乎不怎么听社区的意见，比如 iferr 问题、喊了十年终于加入的泛型等。以类型清晰为优点的语言却有上面提到的 interface{} 类型传值传指针的混乱，错误处理也有 iferr 和 panic/recover 两套，为了“语言简洁”连如此常用的MinMax都要使用者到处写，用户代码的混乱去换语言本身代码的“简洁”。
相比之下一些项目，如 nodejs（实际上前端的大多数年轻项目）的管理模型就民主很多，不是固执老头子单独拍版在做决定。甚至 C++ committee 的运作模型都比 Golang 的强。
最高的梦想是厂们还有猿们能够对 Golang 做 fork（就如当时的 io.js 不满 nodejs 管理模型而做出 fork，但是这个在现成代码量这么大的情况下发生的概率已经好小了。
现在是深夜3点半，脑子也不太清醒不知道在写什么了，大概只是个这段时间来对 Golang 累积的吐槽吧，没有中心没有结论，就这样。