@enchilada2020 #44
不能怪我敏感，而是很多人，就是这种贬低的态度，而且这种措辞确实就是这种效果。
比如这个场景：同公司，你是 A 、一个项目贡献很不错、得到嘉奖升职加薪，同时 B 、C 、D 之类的说“A 不是多优秀，只是这次的项目他刚好以前做过类似的、这次机会赶上了他运气好罢了”。
你可以心胸开阔，听了这种话还很无所谓，甚至自己有城府，不只高兴，还能看出说这些话的人水平、琢磨以后怎么管理他们。但是这种话，多数主角至少心里会有一些不舒服，而且这些话不只是说给 A 听的，A 也得考虑其他人听到他们这么说会对 A 自己造成什么看法和影响。

捧杀和暗贬，往往比直面缺点的批评的破坏力更大。
因为之前讨论 typescript-go 的帖子很多人都是这种暗贬的措辞，我估计，自己被带偏了都不自知，很多人都是被这样带节奏了，自己真正理解了系统工程和语言如何合理有效地结合利用之前、却先陷入了别人这种随风潜入夜润物细无声的话术，这种杀伤力就像一颗小种子被悄无声息埋在了心里，只要你不突破内里，它就越加发芽壮大并成为谬误的参天大树。

你要是认为自己没贬，也不用多解释、这个对咱们都没有利益关系，随意就好。
即使贬低也没关系，每个人对事物都有自己的看法，没必要统一，贬低的人贬低你们的，我支持我的，各抒己见，看见的人自己分析取舍就行了。

但我是建议你认真思考下是不是真的贬低，心理学上不是好几个“我”，说不定是潜意识或者不经意的贬低、自己没意识到罢了。不是为了跟你较真而建议你认真思考这个问题，而是，顺便认真思考不同语言真正的差异和优劣点在哪里。因为很多人夸其他语言和贬低 go ，多数局限在语法糖之类的，根本没理解到系统、语言、算法结构、工程这些真正的痛点在哪里。很多人写代码，只是一份挣钱的手艺罢了，这些人的观点很多不正确、也不重要。但是你标题问这种问题，至少是有工程的思考、不只是挣钱，还有兴趣、追求的成分，多思考些总是好的。

@enchilada2020

> 你好像还是没理解 那句话没有讨论 Go 优秀与否的意思 也不包含对语言的褒贬

那看下官方怎么说的吧：
https://github.com/microsoft/typescript-go/discussions/411

谷歌翻译贴下：
```txt
语言选择始终是一个热门话题！我们广泛评估了众多语言选项，包括近期和之前的调研。我们还考虑了混合方法，即某些组件可以用原生语言编写，同时核心类型检查算法仍保留在 JavaScript 中。我们编写了多个原型，尝试使用不同语言实现不同的数据表示，并深入研究了现有原生 TypeScript 解析器（例如 swc 、oxc 和 esbuild ）所使用的方法。需要明确的是，许多语言都适合从头开始的重写。在考虑了多种特定于这种情况的标准后，Go 的表现最佳，其中几个值得解释一下。 迄今为止，最重要的方面是我们需要尽可能保持新代码库的兼容性，无论是在语义方面还是在代码结构方面。我们预计在未来相当长的一段时间内都会维护这两个代码库。允许结构相似的代码库的语言为任何进行代码更改的人提供了巨大的便利，因为我们可以轻松地在两个代码库之间移植更改。相比之下，那些需要从根本上重新思考内存管理、变异、数据结构、多态性、惰性等特性的语言可能更适合彻底重写，但我们更倾向于将其作为移植，以保留现有行为和我们已内置于语言中的关键优化。惯用的 Go 与 TypeScript 代码库现有的编码模式非常相似，这使得移植工作更加易于处理。Go 还提供了对内存布局和分配（对象和字段级别）的出色控制，而无需整个代码库持续关注内存管理。虽然这意味着需要垃圾收集器，但 GC 的缺点在我们的代码库中并不特别突出。我们没有任何会因 GC 暂停/减速而受到影响的严格延迟限制。批量编译实际上可以完全放弃垃圾收集，因为该过程最终会终止。在非批处理场景中，我们的大多数前期分配（ AST 等）都会在程序的整个生命周期内有效，并且我们拥有关于何时运行 GC 的“逻辑”时间的强大领域信息。因此，Go 的模型在降低代码库复杂性方面为我们带来了巨大的优势，同时垃圾收集的实际运行时成本却非常低。 我们还进行了异常大量的图处理，特别是遍历涉及多态节点的上下树。Go 在使这些操作符合人体工程学方面做得非常出色，尤其是在需要模仿 JavaScript 版本代码的情况下。 承认存在一些弱点，Go 的进程内 JS 互操作性不如其他一些替代方案。我们即将推出计划来缓解这个问题，并致力于提供高性能且符合人体工程学的 JS API 。由于当前的 API 模型，用户几乎可以访问（甚至修改）任何内容，我们在某些可能的优化方面受到了限制。我们希望确保新的代码库能够为更改内部表示提供更多自由，而无需担心破坏所有 API 用户的功能。转向更具针对性的 API 设计，并将互操作性纳入考量，将使我们能够推动生态系统向前发展，同时仍然实现巨大的性能提升。
```

这里面官方主要说的是 go 哪些方面适合，所以相当于说的是优点为主，一些小缺点比如 gc 停顿不影响这个项目。

我没看出来官方有提到“选 Go 不是因为 Go 在语言层面有多优秀”，所以你们的观点里非要无中生有个前置条件“选 Go 不是因为 Go 在语言层面有多优秀”？

泛化的语境下，尤其广大群体里的多数人看到一件比较强的事情的时候，就是喜欢带一句“也就那样”、“也就那么点事没啥了不起的”之类的，所以这种说法实际上的效果就是暗贬。

很多人都是这样子，我自己也一样聊天经常装 x ，但多数是口头、那些无关紧要的，技术相关的逻辑比较严谨的不会随便这样贬、如果贬或者不赞成我会带上实质性的东西，比如隔壁依赖注入的讨论 /t/1131027

@enchilada2020 不需要站队，哪里好哪里不好，都如实说就可以了，例如 go 的性能不如 c/cpp/rust 我也都是这样强调的，因为我自己写 c/cpp 过来的、用 go 爽在各方面平衡但想追求极致性能和把控的时候是真挺无力的。
但是，你们措辞，比如如果“Go 不够优秀”，它怎么达到最符合需求？ c 语法也简单呢，c++也有闭包呢而且可以用像 c 一样的风格也有标准库，为啥不用？

如果按你这思维，我可以扩展下，其他语言没选上，至少有一个方面不如 Go 。
不是针对 c/cpp/rust ，也不是针对 c#、java ，而是 Go 以外的所有其他语言，也都不够优秀！
所以没一个语言是优秀的！

> 最后能选 Go 不就已经说明了它够格的吗

既然够格了，你们还非要加一句：“不是 Go 在语言层面有多优秀”！
你们都是神人，不踩一脚不会说话是吗。。。
我看官方的人好像也提到了 go 的并发、gc 、性能之类的优点吧，这些优点都不叫优秀？我用过 10 种左右语言，go func()+chan 是并发最便利的了
如果只说“Go 在各方面最适合，所以用 Go”而不是捎带一句“不是 Go 在语言层面有多优秀”这种贬低的话是不是更实事求是些？

@matrix1010 #72
其实是一样的，不论大小、依赖的多少，没有本质区别。
你说它不考虑顺序，但你还是要手动去注册这些，用于注册的这些 func 也都是要按格式实现。

mock 的本质是同一类行为，泛化一点多态的概念、可以认为它是一种多态。
oo 可以多态，c++的模板可以静多态，interface 也可以多态，甚至最简单的 callback func 也可以认为是多态，甚至脚本语言里、连返回值之类的格式不一样之类的但只要你可以用统一的方式调用（例如忽略返回值）也可以是多态，再甚至，只要支持闭包、都用闭包也可以简简单单实现多态。

本质上讲，di ，mock 是这种多态，callback （例如 middleware ）也是这种多态。不用 dig/fx/wire 这些，真没感觉任何障碍，包括你贴的 granfana 这段。

@enchilada2020

> 官方给的解释已经很清楚了 选 Go 不是因为 Go 在语言层面有多优秀 而是它是在 *移植而非重写* 这个目标下最符合需求的

能达到“最符合需求”这个至少有几个前提：
1. 性能虽然不如 c/cpp/rust 这几个第一梯队但也是第二梯队并且性能足够
2. 并发便利
3. 自带 gc 内存管理没什么心智负担
4. 跨平台友好
。。。

所以，并不是因为 go 在语言层面有多优秀。我希望你们能加一些个定语，比如“相比于 c/cpp/rust 的性能不够好”之类的。相比于某个语言的某个/某些点不够好，不意味着 go 本身不够优秀，go 的最大优秀的点是各方面比较平衡然后非常利于工程性，在你们眼里就非要这种不够优秀的措辞，真是服了你们了。

讨论这些话题都落实到具体点上了，我不是为了很多人口中所谓的 go 邪教，而是看不惯你们这些人不懂还要顺便踩一脚的酸劲。

@matrix1010 #70 但这里的 di 并不是必需品吧

相比于：
err = container.Provide(ai.NewAiService, dig.As(new((ai.AiService))))
if err != nil {
panic(err)
}
err = container.Provide(table.NewTableService, dig.As(new((table.TableService))))
if err != nil {
panic(err)
}

简简单单的这种也可以：
aiService, err := ai.NewAiService(...)
if err != nil {
panic(err)
}
tableService, err := table.NewTableService(config, db, aiService...)
if err != nil {
panic(err)
}


多个 Provide 的都是这种，而且每个 Provide 也都有 if err ，真没看出来哪里变得简化了，反倒增加了 di 本身的隐含逻辑需要额外去理解、更绕了
这里最核心的能够方便 mock 的，就是 dig.As ，而这个本质上是实现 interface 。
至于 di 本身的逻辑、对于熟悉设计模式熟悉 di 的人当然不算什么，即使不懂的人简单看看也不算什么负担，但相比于本可以简简单单的方式，毕竟还是多了一道弯弯绕

看了下 linkedin ，这种水平和服务微软这么多年竟然只是“Senior Software Development Engineer at Microsoft”，看样子是真的不懂人情世故了，跟弱肉强食一样，世道对老实人不公才是自然法则，真没办法。

@fds #67 看了下 fx 教程的例子，像是得了什么大病才能把本来简单的事情搞得这么复杂。。。

@zaihuilvcha #68 抛开事实效果就说是邪教——这本身也是一种邪教思维，建议就事论事。

@momo2789 #66 我看过的绝大多数优秀项目源码都没用 wire ，确切地说，我个人视角比较局限、看过的所有优秀源码或者源码模块都没用 wire 。

@latifrons #34 没有 di 也没遇到过这些烦恼，难道没有 di 就没法实现这些了？增加了 di 反倒把这些实现看上去更复杂了，多数是设计模式的重度用户觉得没有 di 不好罢了

@matrix1010 #4 比如 net 包用于测试的 type pipe struct ，很多实现 interface 即可。我到现在都没搞懂依赖注入到底是啥，看一两分钟就觉得是在把简单问题复杂化所以实在花不了时间深入研究它到底是啥，关键是，现实中没有遇到不用它就搞不了的场景。

保险保险，谁投保、谁承担资金损失风险

笑贫不笑娼，找个工作没什么
尊重他人的命运，也尊重他人的努力，不必相轻
推荐《当幸福来敲门》

赞同。

附加个建议：自己处于水平一般的阶段，应该多看多学，自己理解不深入的时候少输出错误技术观点误导别人。