> 选择的核心不在于 Go 有多优秀，而是契合度，在同等性能的这个梯队中，没有比 Go 更合适的了。tier2 的性能 + 简洁的并发设施 + 带 GC 的类 C 语法 + tier1 的交叉编译能力，从这几个维度去考虑 Go 的契合度就是第一的，这是从工程角度去衡量，而不是语言设计。

@sagaxu #62

优点的列举我都赞同，唯独第一句 “选择的核心不在于 Go 有多优秀” 我是不赞同的。
Go 的各方面设计是在工程实践上取舍出来的非常平衡的，如果因为某个方面不是最佳，或者其他语言也有，所以 Go 就不够优秀，那语言是否优秀就只能看某一方面了，比如说性能或者语法糖。

看看这些点：性能好又带 gc ，跨平台交叉编译，简洁的并发设施，类 C 语法的简洁，不用处处搞 Class 、简单的东西不用搞复杂的设计、开发效率。。。
每个点，都能淘汰掉一些或者一类其他语言，这些点又都是工程实践里非常给力的点，这些点都能满足的，几乎也就 Go 了，如果满足了这么多看上去不突出的优点，加起来却还是不够优秀，我真不知道什么叫优秀。
加上 TS 编译器 port 这个 case 叠加 Go 与团队原来使用 JS 方式相像叠加优势，Go 在这次选型中更加优秀，但这个更加优秀是以 Go 本身优秀为基础的。

对 Go 或者编程语言的评价，其他帖子或者楼层也有好多人是类似的说法，我看到的现象大概是：只要某些方面不是最好，那就不够优秀。
我们经常会谈论到木桶理论，谈论到解决短板瓶颈，为啥谈到语言优秀的时候又不这样认为了？
Go 在工程性、性能、开发效率等各个方面做到了很好的平衡，Go 让木桶每根板子都不算短，为了让每根板子都不成为短板、所以也没在每个方面都成为最长的板子、因为鱼和熊掌不可能兼得、做不到所有板子都最长。
但就这么一个板子均衡的木桶，却不优秀！
能非常好的满足工程需要的均衡木桶型的工具，却不优秀！
这是什么优秀论？！这是过于苛刻的极端的评价方法，是脱离了实际的评价方法

正是因为很多人觉得 Go 每个点都不是”最突出“或者其他语言也有，所以才会有很多人不屑地觉得“Go 不够优秀”或者”Go 也就那样“。
以至于一些人看到官方那个 issue 里提到的主要是因为 Go 和原来 JS 代码比较像所以用这个作为主要原因，比如 @stimw #6 里贴的 issue 。
但正如我前面说的：
”要说像那还是 TS 自己跟自己最"像"、本来就是自举何必要换语言重写呢？“

用 Go 也好，用其他语言也好，前提是：这个选型的语言能够满足提高性能和体验的需求。
选 Go 的前提是 Go 本身已经有了足够优秀的基础，而不只是因为它比其他语言更像团队之前对 JS 的使用、但 Go 不够优秀。


同样回复几位：
@stimw #6
@Nugine0 #54
@DrakeXiang #66
@InkStone 前面提过我没说出 Go 任何优点，我没说是因为采访贴里已经列出来了很多，我没必要去一一重复，我反驳是因为这么多人都认为 Go 只是因为像、而对 Go 本身的这些优点的前置条件视而不见

@InkStone #48

> 底层部分是原文内容。开发者特别强调了他需要 Go 的底层能力——事实上性能提升也多半来自于此。把工程从高抽象层次的实现改到 native 语言，天然就会获得巨大幅度的性能提升。

这些底层能力是只要你用 Go 就有了，并不需要你特殊去使用底层怎样。你前面#42 说的是：Go 的底层操作并算不上很好用。
Go 本身的底层能力天然获得大幅提升，和你说的底层操作算不上好用，没关系吧，所以你后面的解释，和自己的观点都对不上、和我反驳你前面的点也是对不上的

> Go 的优点在各种语言中并不算特别突出，缺点比 Go 少的语言更是数不胜数。

这个#19 我已经说过了：Go 很务实，有的人认为他平庸，简洁、甚至 N 倍性能提升都进不了这些认为 Go 平庸的人的“法眼”。

采访里的大佬也说了的：
“你必须明白，Go 在设计上是平庸的；它并不想花哨。”
Anders: 它试图成为一种简单的语言——说实话，确实如此。但结果并不平庸。我的意思是，10 倍，这完全不平庸，对吧？所以，你可以用这个东西做伟大的事情。

但我能猜到、这种大佬也是入不了认为 Go 平庸的人的“法眼”的。所以咱们争论是没什么意义的，你们说服不了我，我也说服不了装睡（或者其实是达不到装睡水平）的人

@InkStone

以往的技术帖子也都一样，除了偶尔插科打诨，技术问题我都是尽量实际出发的，讨论的点都是带着实际内容的。。。

所以遇到很多类似这个帖子里的情况：
1. 根据采访内容能得出因为 Go 和 Js 像是用 Go 的主因。。。
2. 我用事实论证能推出我是因为喜欢 Go 。。
3. 我用自己的亲身体验论证不是因为我喜欢 Go 而说 Go 好，被推论出我是在炫耀自己会得多。。。

我也是挺诧异的，到底如何实事求是地讨论技术问题

> 难道你以为就你一个人写过十几门语言么？对能独当一面的开发者来说，这都是最基本的好吧。

@InkStone 我这个是用来反驳你说我因为喜欢 Go 、说明我是实事求是的，并不是自吹，也不是假设你们其他人不懂多门语言。但既然也都搞过那么多，还能得出这样的结论，确实就是#37 这种本末倒置了，造成这种情况，可以认真考虑下#43 、然后优化优化知识结构。。。

@InkStone #44

我这可都是实事求是啊，不像你们直接说我因为喜欢 Go 而怎样。。。#43 这种我分析的也是多年来看各种技术讨论对这类人和现象原因分析的总结啊，相信我，琢磨一下，可以大大提高自身境界。。。

@InkStone #42

> 这就是为什么我说 Go 支持底层操作之类的只是特点而不是优点。

我甚至都没理解，你说的底层操作这些跟这个帖子本身提到的重写 TS 编译器有什么关系，重写 TS 编译器这个用到的 Go 的好像都是基础部分、不涉及底层吧，如果是说没有字节码、语言性能以及并发便利和性能本身这些都与用 Go 底层没什么关系的。。。
如果抛开这个帖子谈底层，绝大多数搬砖的都不需要用到 Go 底层，Go 为了方便大家提供了优秀的标准库已经非常大地解放大家的生产力了。。。
而至于真正需要搞底层的，又有哪个语言的底层是好用的呢？除了 c/c++因为系统就提供 c 接口、其他语言的底层也没怎么好用，但是 c/c++除了跟系统亲近、做应用层的效率也太拉了，所以也完全没必要用来对比。。。

> Go 的缺点大家都说过很多了我也懒得说了……现在不是别人没正视 Go 的优点，而是你没正视 Go 的缺点。

很多人所说的 Go 的缺点，恰恰是优点。Go 的一些缺点我知道，但是瑕不掩瑜。哪个语言没缺点呢？但是哪个其他语言的缺点少而且优点又像 Go 这么大呢？
鼓吹 Go 这不行那不行的人们，多数是我#43 说的这种，一叶障目罢了

@InkStone
很多人因为自己学过什么，就会有什么的思维惯性，然后对其他的异类事物会有抵触，尤其是如果自己所学的东西看上去更加复杂、先进，比如花样多、语法糖多、语言理论现代化，看上去好像很高级，就会反对看上去更加低级的比如 Go 。
经济学上相当于沉没成本效应，心理学上大概叫首次效应，玄学上这叫迷了眼

真正成为语言邪教的是这种人，而不是抛开这些花哨、踏实从工程角度去考虑工程实践的实用主义的人，谷歌早期宣传的时候的定位，就是这种工程实践的实用主义哲学、以及很多人眼中所谓的和嘴上黑化了的"大道至简"，只顾皇帝的新衣不看内里，是做不好实事求是的。

@InkStone #38

> 事实上，里面提到的 Go 的优点就是一条：并发编程支持好。

所以现在你的观点里增加了一条 Go 的优点，我多少欣慰了一点。。。

> 其它的都只能说是“特点”。比如本身支持底层操作（底层语言不支持底层操作这像话吗？），有 GC ，编程范式和 tsc 原有的实现方式接近等等。

支持和好用是两码事，其他很多语言也都有“协程”之类的，但是好不好用？我个人从早期的 lua 、erlang ，到现在的一些语言的 async await 或者 virtual thread 大概都了解过一些，只能说 erlang 的进程和 goroutine 是一样好用的、但 erlang 本身比较拉，其他的，让我实际工作中去用我是不会去这样糟蹋自己去用的

> 当然，真说起来，说 JS 和 Go 像确实也没那么贴近事实，更贴近事实的是：Go 和 tsc 里使用的那一部分 ts 语法子集（接近于带 typehint 、不怎么玩 prototype 等花活的 js ）很像。

“真说起来”，那肯定是不像，但人家只要有采访中提到的这部分相像就已经足够作为多个语言中选型的重要理由之一了。
实际上这个选型主要是两个维度：
1. 是否能实现性能优化和体验的提升：为了达到这个目的 c/c++/rust/go/c#等语言都可以
2. 在满足 1 的前提下，重写编译器的工程效率，因为考虑到已有的 ts/js 的可重用性，go 与 js“相像”这个优势就凸显出来了

> 你喜欢 Go 的心情我能理解，但自始至终你都没说出什么 Go 什么优点来，这实在有点难绷……

我从没有因为自己喜欢 Go 而去盲目吹嘘 Go 的好或者贬低其他语言的不好：
1. 我说 Go 的好的时候完全就是因为我认为这些点真的好、并且是我亲身体验的好
2. 我说其他语言的不好的时候完全就是因为我认为这些点真的不好、并且是我亲身体验的不好

我自己干这样差不多二十年了，学习、体验过十多种语言，实际项目中用到过的至少写了几千几万行的代码的包括 c/c++/lua/py/c#/js nodejs/as/go 各种，好和不好都是亲身体验和总结，不是站队性质也不是跟风性质的观点输出

首先，我没说 #12 AI ，是不是 AI 不在我观点范围，我只针对 #12 内容合理性。

> 比如 LLM 胡扯的什么「集成优势」，人家原文（甚至都不在上面的采访里）的意思是 Go 的缺陷正是难以集成，LLM 直接颠倒黑白了，把劣势当优势了。

> 还有垃圾回收是相对于 Rust 说的，简单性是相对于 C# 说的，以及受访者最想强调的 OOP 缺陷，大模型完全没理解也没提到，我不知道你说的「总结得好」是什么意思…

@w568w #25

你这里说的「集成优势」是指这个吧：``Go 语言可以更容易地与现有的 TypeScript 代码库进行集成，这可以简化重写过程并减少潜在的错误。``

注意，#12 总结的是 ``与现有的 TypeScript 代码库进行集成``，你看采访内容（包括这段紧接着的更多函数化相关的）：

``对于我们来说，另外一件事是我们的 JavaScript 代码库是以高度函数化的风格编写的 —— 我们使用很少的类；事实上，核心编译器根本不使用类 —— 这实际上也是 Go 的一个特点。Go 是基于函数和数据结构的，而 C # 是高度面向对象继承的，我们必须切换到一个面向 对象范例才能转移到 C # 。这种转变将涉及更多的摩擦，而不是切换到围棋。归根结底，这是我们阻力最小的道路。``

JavaScript 代码库是以高度函数化的风格编写的，很少使用类，他们已有的 JS 和 Go 都不重 OOP 、风格相近 -> ``与现有的 TypeScript 代码库进行集成``，这里说的集成可不是你说的「集成优势」，你这个「集成优势」太宽泛了、单独看我会理解成把互相接入、跨平台部署之类的也考虑进来

#12 的总结，整体上我觉得是合理的

@InkStone #33
你可以看下隔壁#12 的总结，前面几条可都不是因为 Go 跟 JS 像，用 Go 重写 TS 编译器也不是因为 Go 像、重写 TS 编译器本身的目的是在于提升 TS 编译器的性能和体验。

要说像那还是 TS 自己跟自己最"像"、本来就是自举何必要换语言重写呢？
所以，得出 Go 和 JS 像是原因这种结论，可能是因为自己对 Go 的刻板印象、首先默认 Go 不行、然后拿着结论去找原因，本末倒置了、推导的方法不对、第一步就错了

@InkStone #33 我说的都是内容的实质、不乱哪个帖子、Go 的优点都在那，所以其实是哪个帖子根本不重要

@redbule 是的，所有天生 OOP 以 Class 为主要模式的，都有这个毛病，十多年前没有这么高速发展的 IT 互联网的时代，还好，时代变了之后，业务种类和规模越来越大了，需求迭代越来越快了，OOP 尾大不掉、顶层设计难度和开发效率拉垮。所以很多独角兽在没有历史包袱的领域大量用 Go 从头造甚至抛弃旧的技术栈用 Go 大量重构，国内一些明星企业做了太多这种示范了，但就是有很多人看不懂、无脑喷 Go

> 我想主楼已经说得很清楚了，选用 Go 不是因为 Go 多好，而是因为 Go 最像 Javascript

@InkStone #22

得出这样的结论，我大概也懂了为啥你们认为 Go 平庸——Go 的优点一点都看不到或者不承认

只能建议看下隔壁帖子了：
/t/1117764

你们认为 Go 平庸就认为吧，#19 里我已经说过了

看到过好多次说 C#比 Go 好的了，希望这个事情让你门清醒。。。

BTW ，这事情里的函数式不是通常说的函数式编程
函数式太多花活、隐藏机制、性能浪费，不是什么好玩意
OO 太多累赘、啥都得 class 、顶层设计难以预计未来、难以高效应对快速变化，不如面向过程更加通用

Go 很务实，有的人认为他平庸，简洁、甚至 N 倍性能提升都进不了这些认为 Go 平庸的人的“法眼”，反过来还要喷“大道至简”，我无法对这些人的智力水平作出评价，因为我不想贬低别人但也更不想撒谎。

> 内容用 AI 回复 100% 封号，且用且珍惜。

@w568w y1s1, 我个人觉得还是 #12 总结的比较好。。。

@voidmnwzp 汗毛有点重，所以是“看上去胡子”。。。

老夫唯一一次相亲经历，将近二十年前，妹子深圳的，家里条件好得很，名校金融专业，研究生学历，银行工作，风趣幽默思想 Open ，谈吐大方得体，也不嫌弃我农村穷小子，大家非常聊得来，可惜我少不经事、不懂珍惜，只因为妹子看上去胡子比我多就轻易放弃了

中医是伪科学，我赞同，因为遇到过几个庸医真是垃圾、喝他们开的药治不了病反倒更难受。
但是中医经过千百年实验统计学得出的那些常见病或者特别对症的病，总结出来并且经过大量病人案例验证的比较成熟靠谱的方子和治疗方法还是挺不错的，当然前提还是：遇到一个靠谱的医生。西医有相对严谨的方法论，中医全靠医生自己发挥，太难筛选靠谱的中医了