XX 语言的设计确实在特定领域（如并发、微服务）展现了优势，但其信徒将"功能缺失"强行解释为"哲学优越性"，却对实际开发中的妥协视而不见。这种逻辑的本质是：用设计目标的合理性掩盖实现手段的局限性。当一种语言将"我们没有的功能都不重要"作为教条时，它已从工具异化为信仰。

遇到问题擅用排除法，首先不是 PHP ，因为 PHP 是世...

遇到问题擅用排除法，首先不是 PHP ，因为 我不允许有人诋毁 PHP [狗头保命]

我是老实人，这应该是说 Go

这不就是小仙女惯用的“抛开事实不讲，难道你就没错吗”的 pua 法吗，不管你做了多少，说你有错你就有错

任何语言都有优缺点。比如 Python 3 ，创建只有一个字符串的 tuple ，你去看看有多少人不知道怎么写，以及写出来的正确的代码有多难看。但 Python 的生态太好了，我又很喜欢。

a = ('234',)
a
('234',)
type(a)

是这个？难看吗？还是我写错了？

在我看来，不管是将 GO 的"功能缺失"强行解释为"哲学优越性"，还是以内存安全为由在各种项目上强行推广 rust ，这些行为都属于忽略实际条件去强行套用解决方法，本质上是编程领域的唯心主义。这种工具崇拜不仅引发争论污染公共讨论空间，也无助于提高自身水平。
必须认识到，编程的价值在于解决实际问题。脱离工程背景无限拔高某些设计取舍只能暴露自身视野之狭隘。
保持对技术本质的清醒认知，才能在快速迭代的生态系统中构建可持续的工程能力。
我最多只能说：在我遇到的某个特定场景下，使用某些语言/工具是合适的。但是绝对无法断言，这些语言/工具能满足任意场景的需要。
不过我倒是不反对在工程上的约束较为宽松时（比如不涉及合作开发的项目、性能不关键的项目等等）使用自己最熟悉/最喜欢的工具。

我看第一句话一眼认出是 go ，主要 并发 优势的语言确实有且只有 go ，相当于是点名了，后面的话明显黑前面的语言。

先搞懂什么叫"功能缺失"吧。

中国人习惯用筷子和吃中餐，欧美人习惯用刀叉吃西餐。
一些人用刀叉吃西餐的人觉得自己才是吃饭正统、不用刀叉西餐就扣帽子成"功能缺失"。
和着不用刀叉不是西餐就不是吃饭了是吗？

基本逻辑都不通的所以高级工具使用者，实际工程能力如何不得而知，给别人扣帽子的狗屁逻辑倒是真的精通和显而易见

都说得这么明显了，肯定不是说 Erlang

又黑我 PHP

世界上只有两种语言，挨骂的语言和没人用的语言。语言方面我反正已经妥协了，返璞归真，大道至简，一把梭就是干，维护不动了就弃坑留给下一个幸（ dao ）运（ mei ）儿（ dan ）。

我是老实人，这肯定不是 GO

我是老实人，我知道是说的 go 。表达这个观点的是黑 go 的，op 也是。

我最多只能说：在我遇到的某个特定场景下，使用某些语言/工具是合适的。但是绝对无法断言，这些语言/工具能满足任意场景的需要。

我好像从没见过 gopher 和 ruster 去鼓吹任何项目都用 go 或者 rust 去做，至少不是这两个语言社区的主流意志。所以，很迷惑，经常无法理解为什么会有这么多人得出这种结论然后给 go 和 rust 扣上这种帽子。

在我看来，不管是将 GO 的"功能缺失"强行解释为"哲学优越性"，还是以内存安全为由在各种项目上强行推广 rust ，这些行为都属于忽略实际条件去强行套用解决方法，本质上是编程领域的唯心主义。这种工具崇拜不仅引发争论污染公共讨论空间，也无助于提高自身水平。

没人强行推广 rust 去做 curd ，而且一些强行推广的行为已经上升到 us 政府行为，这种强行是基于安全问题日益恶化并且内存安全问题占的比例非常大、c/cpp 又无法解决这个问题。如果只考虑自己 curd 舒服，那当然无法 get 到这种强行对世界的意义，但这世界不只是为了我们 curd 服务的，而是反过来、curd 是为这个世界服务的，不要拎不清。

必须认识到，编程的价值在于解决实际问题。脱离工程背景无限拔高某些设计取舍只能暴露自身视野之狭隘。
保持对技术本质的清醒认知，才能在快速迭代的生态系统中构建可持续的工程能力。

这就更逗了，别人用语言是为了做工程，然后被一些用语言缺少语言自己的功能/特性扣帽子。
我就好奇了，你们那么多人都是在做开发编程语言的工作吗？所以某个语言没有某个或者某些语言特性就是“功能缺失”了？人家做工程好好的、人家语言现有特性能够做工程，怎么就功能缺失了？

为什么这么多人基础逻辑都搞不懂还要对别人务实做事的指手画脚。

大部分人是能够做到根据实际情况做出技术栈的选择的。但是问题在于一部分用语言圣战掩盖自身无知和懒惰的人发出了巨大的噪音。

这部分人无限拥护自己所支持的语言的目的不是为了使某个项目变得更好，而是为了通过语言斗兽棋强行体现自身优越。

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

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

我赞同你的 curd 是为这个世界服务的观点，在兼具高性能和安全要求的地方推广 rust 无可厚非。

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

徒增功耗 感知不强 方向错了

不确定说的是什么语言，但是说这话的一定是 javaer😄

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

我不知道这是不是你工作中同事在做的事情，我觉得大概分两种：

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 麻烦些，甚至以前没有范型、要为不同类型都写几个相同实现，但这些多数归属于简单的逻辑、稍微花点时间就可以搞定了，并没有真正消耗开发效率。

看到微服务: go?
但其信徒将"功能缺失"强行解释为"哲学优越性": 这不是某某经常说的 "大道至简"吗? 一点语法糖都没有,简你个头,一行的事情非要几行。
却对实际开发中的妥协视而不见: 啥都要自己造 问就是大道至简。