离谱， TypeScript 的主力开发之一 Ron Buckton 被微软裁了

@iyiluo 就是说啊，，离谱得很

@ryougifujino 70 歲了 可以退休了

微软好像裁 3%，大概 6000 人左右

我个人觉得大的还在后面，现在不过是百年寒冬的一点冷气而已

ts-go 的时候就应该是想好自立门户了，不用 c#，也应该是 cpp 吧

@foolishcrab #1 懂业务没用，说一千道一万，能给公司带来利润的部门才是王道。在企业中，谁能赚钱谁就是王

@zeromake 微软本来就有砍刀部

@FengMubai #26
我有点分不清，你想和我说什么，砍刀部和有没有赔偿有关系吗？能说一下吗？

@songray react native 再上一分

只能相信微软了

要不四端开发的却扛不住

@zeromake 回复错人了

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

@liuidetmks 这倒也不是。。官方给的解释已经很清楚了 选 Go 不是因为 Go 在语言层面有多优秀 而是它是在 *移植而非重写* 这个目标下最符合需求的：
尽可能高性能 适合来写编译器 且自带垃圾回收机制 1:1 移植后的代码尽可能跟 TS 版本保持一致 减少语法/语言机制方面的差异带来的额外工作量

不选 C# 是因为 C# 以 OOP 为主要范式 写法上差别比较大
不选 Rust/C++是因为没有垃圾回收机制 需要手动管理内存
所以如果使用以上被反复提及的语言 相比现在 TS 代码会有额外工作量
而 Go 刚好也有 duck type 也不 OOP 自带垃圾回收 且性能算比较好的（打不过 Rust 至少打得过 JS ）所以就胜出了

@Gilfoyle26 实话 其实同级别销售不比技术赚得少

@enchilada2020

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

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

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

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

@lesismal 哥 别误伤友军 我可没说 Go 不够优秀。。重点是在说明此次移植不是从语言偏好/表明立场/站队/另立门户/blahblah 而是从实际需求出发的 那么多方面的考量下 最后能选 Go 不就已经说明了它够格的吗😂

@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 在语言层面有多优秀”这种贬低的话是不是更实事求是些？

@lesismal 啊这。。你好像还是没理解 那句话没有讨论 Go 优秀与否的意思 也不包含对语言的褒贬 而是在强调是从需求而非语言层面上出发的 咋就成了贬低 Go 了呢。。

ceo 为公司股东服务，预期业绩不行的时候，就开始裁员搞事。美国经济环境乱得很，大公司为了保自身，放弃开源项目都不稀奇。

@ChefIsAwesome 虽然可能性很低 设想了一下 如果微软哪天突然抽风 宣布放弃布局了这么久的 TS 那可真是有意思了。。

@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

微软的办公室政治, 安德森也得受气