lesismal

> 大部分人是能够做到根据实际情况做出技术栈的选择的。但是问题在于一部分用语言圣战掩盖自身无知和懒惰的人发出了巨大的噪音。
> 这部分人无限拥护自己所支持的语言的目的不是为了使某个项目变得更好，而是为了通过语言斗兽棋强行体现自身优越。

我不知道这是不是你工作中同事在做的事情，我觉得大概分两种：
1. 那些业务量用原语言没有瓶颈的且有大量历史包袱的，没必要换语言去重构的项目，被很多人鼓吹换技术栈重构
2. 但一些明星企业搞了大量的 golang 重构也是属于刚需：性能的刚需和成本的刚需。很多 curd 的人不喜欢，但重构确实带来了很大提升

如果是因为 1 让你不爽，那确实是倒霉，但不应该根据 1 去否定 2 ，也没必要去否定某个或者某些语言的社区，真理掌握在少数人手中的情况很多，一个好的语言火起来、很多无脑拥趸跟风的人会来污染这个事物、但他们不一定是社区主流、也不应该成为社区主流，所以我个人和很多同行也是不喜欢看到很多其他语言涌入到 go 里然后用其他语言的方式去搞 go 。

> 内存安全的 rust 是很好，但是如果没有在延迟上有特定的要求，我可能更倾向于支持 GC 的语言。

强推内存安全不只是强推 rust ，java 、go 也都在推的，可能是因为 rust 自己更加突出地标榜自己的内存安全，所以很多人误以为推动内存安全就是推 rust 。性能和安全都要求特别高并且性能要求极致的 rust 是最佳，否则 rust 的开发效率也是感人、没必要。


> GO 无脑堆逻辑确实快，但是占一多半的 if err != nil return nil,errr 也确实碍眼。

这个怎么说呢，如果不是 go 这么要求，go 代码可能也不会这么健壮。

如果仅以所谓代码行数少带来的简洁性作为审美、并且用审美大于实用的标准要求自己的代码，那应该搞艺术，而不是做工程。你也提到根据实际情况做出技术栈的选择，这是务实的观点，务实不只是选择用什么，怎么用也是务实的一部分，毕竟如果不喜欢，大可以 “_” 忽略 err 和处理、可以不用去写 if err else 。

> 语言的特性是一个事实，没有一个功能或语法就是没有。至于是否属于功能缺失，我觉得判断标准确实要落在是否影响实际工程应用上。

至少我没有遇到过因为缺少其他语言的高级特性导致工程效率低，确实有一些小的麻烦，比如 err 处理的行数多些，以往用标准库 raw sql 循环 scan 麻烦些，甚至以前没有范型、要为不同类型都写几个相同实现，但这些多数归属于简单的逻辑、稍微花点时间就可以搞定了，并没有真正消耗开发效率。