@Nugine0

我多解释下吧，我前面说那些“不是 Go 多优秀”的，不是指你 #54 是在说 Go 不优秀
at 你是因为 #63 说资历的问题，但本质上不是因为你说的资历问题、因为你没有明确指向谁
但是因为 #44 认为我是因为喜欢 Go ，我为了解释不是因为喜欢 Go 而怎样所以说了#41 结尾
而我也并不是在用资历说事情、因为工作十年二十年仍然是 curd 搬砖的人多了去了、资历并不代表水平，我说自己的经验和多个语言的体验对比里得出的结论罢了
因为没看到其他楼层有类似与资历有关的问题、似乎只有我提到的这个是与资历有关的所以觉得 #63 似乎是和 #44 一样在指向我
所以答复那些“不是 Go 多优秀”的时候顺便 at 里你，然后你就同样来辩论优秀不优秀的问题了


> 我并不认为要求别人给出“优秀”的评价是一种客观的做法。

我没有要求任何人给出优秀评价，而是反驳这些人，为什么如此了还不能称为优秀。


> 本来给出正面评价、想避免引战的人，现在会附带一些个人看法。

如果因为我的观点就导致了你带个人看法，那我表示抱歉
但我建议不要这样、这相当于丢掉了自己的理性判断，没必要
即使 ruster 再狂热，我也不会去放弃支持 rust


> 你也不用告诉我解法，这些坑我都知道。只是想说，在体验过这些后实在是不能称其为“优秀”。

你列的这些点里，几乎没有对我造成过困扰、或者即使造成困扰也是微不足道的，相比于整个工程和性能效率，实在是没什么值得纠结的。
我不知道为什么人们总是喜欢用蹩脚的姿势或者稍微麻烦一点点都觉得是大问题，或者对年轻语言连点耐心都没有。

还有前面提到的“再加上社区提案爱答不理，谷歌需求立马安排，这种行为实在是难绷”，我是大力支持官方的，随便个什么提案往里乱加只会让 Go 变得更差，缓慢迭代这些是好事情。Go 官方和 Linus 的霸道风格我都大力支持！

@Nugine0

> 那我只能说，批判别人“没说优秀”的行为只会把别人推向反面了。

自己具有一定水平和判断力的人，也不会因为别人的态度就站在了反面

@Nugine0

> 那我只能说，批判别人“没说优秀”的行为只会把别人推向反面了。

本来就能自己判断和认同的，不需要去劝导加入；
本来就不觉得它优秀的、也没站在它这边、而且所谓的客观评价造成的效果其实就是反面。如果没人出来说明，只会让更多人站在反面，所以总不能因噎废食、只让反面效果的事情野蛮生长吧？

> 优不优秀是主观看法，不符合我的需要和审美，就是不优秀。这是没法客观论证的。

每个人有自己的主观，我和其他人也没有强求去改变单个人，但是要澄清各自的观点，避免造成反面效果的客观评价称为主流

很多人开始用 Go 后最爽的是写同步代码并且不影响性能，不用担心 java spring 之类的线程池耗尽或者要去用 netty 搞回调，还有 go func() chan 、不用遍地搞 class 的各种方便，很少有人说 Go 爽是因为语法糖真丰富，很少有人沉迷于 Go 里茴字有哪 N 种写法，工程上的好处是实实在在的，但很多人的水平没到理解系统和工程的层次、他们是看不到的，很多人更在乎自己写代码奇淫巧技咬文嚼字的那点东西，所以会喷大道至简各种


> 能客观论证的是哪些方便做，哪些可以做，哪些做不了。

客观的 gopher 就是这样做的，包括我自己，自己项目适合哪些不适合哪些，其他选型哪些比 go 更适合，都是客观说，我没见过极端狂热的 gopher 去吹嘘 xx 功能只能用 go

性能要求特别高的场景，Go 就是达不到第一梯队，所以除了少量人在那用 Go 造缓存甚至数据库的轮子并且定位为取代传统性能语言，其他清醒的人很少去鼓吹这种，我是直接反对这种的


另外，很多人评价编程语言都有点脱离实际了，脱离工程实践：用设计和实现编程语言本身的标准去评价一个编程语言，脱离了绝大多数人使用编程语言是用于工程实践的实际情况。
比如：那些编程语言设计的相关理论，比如高级语法糖要比性能 N 倍的提升更好。
当然，如果项目本身对简洁没有要求，对性能没有要求，对工程管理没有要求，对很多都没有要求，随便找个什么模板或者老代码改改就能跑，都很高效率，如果都是按照这种出发点，我说的 Go 的优点也好缺点也好就都没意义了。

> 你不能按“没说优秀就是否定优秀”来判定

@Nugine0 严格来讲不是否定，但在宽泛的社交语境，这约等于否定、并且实际效果就是偏否定的

> 或者对“不懂得独立思考”的人的影响来判定

这个是事实，而且不只是编程领域

1. 性能很好，但是：性能不是 Top ，所以不是它优秀；
2. native 并且带 gc ，既有性能又不需要为内存管理太操心，但是：其他一些语言虽然没有 gc 但也是 native ，其他一些语言 3. 虽然不是 native 但是也有 gc ，所以不是它优秀；
4. 跨平台支持够好，但是：其他语言虽然性能可能不那么好而且字节码，但也有跨平台够好的，所以它不是优秀；
5. 语法简洁特性少，很明显：缺少高级特性，不够现代化，“大道至简”就是笑话，所以它不是优秀；
最方便易用的并发，但是：其他语言也有并发，虽然用起来麻烦点或者性能不够好，但反正别的语言也有，所以它不优秀；
。。。

我真想知道，什么才能被称为优秀。

@sagaxu @Nugine0 #77 如果是重写不是 port ，那我肯定是推 Rust 的，因为最大目标是提升性能和对应的体验，Go 性能这点就可以被第一轮淘汰了

@sagaxu @Nugine0 #73 #76

你门说的我是理解的，我也从来没说 Go 一枝独秀，因为除了 go 和 chan 和简洁，Go 的性能肯定是达不到第一梯队的，Go 对我而言、最重要的是各方面的平衡。
你的评价是相对客观的，但仍缺少一种对普通优秀的认同。这种缺少，会让其他那些不屑甚至贬低的 Go 的人拿去发扬光大，在这些人眼里去看你门客观评价的这种“不是 Go 多优秀”，就会变成了 Go 不优秀。

优秀不需要就是最好，更不需要每个方面都是最好，如果不是最好就不优秀、那就只有每个 Top1 才能作为优秀了，我觉得这是不合理的。
而且话说回来，从平衡的这个角度，Go 已经差不多是做的最好了。
在否定了 Go 优秀的前提下，以 port 这个 case 为主要原因、对 Go 的评论就显得不够客观了。

各位再去品一品这些评论给大家带来的是什么印象？
给我的感觉就是：
TS 小姐姐男友 x 能力不行，要换人：
ABC 因为 xx 方面不行被淘汰了，EF 因为 yy 方面不行被淘汰了；
剩下 G ，各方面都还凑合，但是他会的其他几个也分别有人会、他有的其他几个也分别有人有；
并且某些方面别人比他强，比如有的 x 能力比他强，有的打扮花哨比 G 更加帅气姿势多骚气逼人；
所以，其他人都因为某个或者某些方面不行被淘汰了，只能无奈选了 G ，有个好处就是 TS 小姐姐还是喜欢现任的颜值、G 跟现任很像；
但是呢，虽然选了 G ，但是 G 你资质平庸甚至长的简陋有点丑、你根本就不优秀，选你但还是看不上你，要不是其他人都不行谁 tm 选你啊；
能被选上，G 你就自己偷着乐去吧！

很多人对 Go ，就像是见不得别人好，绝不会夸它的，甚至要不屑、贬低，加之各位这种自认为客观评价的措辞、他们会借来变本加厉。
太多人嘲讽 Go 的 err 处理，太多人嘲讽 Go 的大道至简了，太多人嘲讽 Go 的粗鄙简陋缺少高级特性了。。。
但这些人里：
多数也没搞懂异常和错误本身就是两码事，用一些其他语言抛异常搞定天下去套所有语言，连入乡随俗的道理和鲁棒性都忘记了，就像是校霸来了学校、鬼子进了村一样蛮横；
多数也没搞懂什么是大道至简什么是 less is more ，只自顾自兴致勃勃爬上屎山也拉个够；
就像他们习惯使用的其他语法糖丰富的语言是奢侈品名车名表名牌包包一样，用了这些高级货让他们走在人群中都会闪闪发光一样，但凡用 Go 就是 LowB 村夫。。。

我也不是要去大夸特夸说 Go 多么多么比其他语言优秀，但是我发现了，越来越多的人在嘲讽 go 的大道至简嘲讽语法简陋嘲讽增加鲁棒性的错误处理用其他语言的习惯去要求 go 要有这个要有那个，或者像很多人看似客观地评论 go 是平庸的并不是很优秀。
这些看上去有道理的话，让越来越多的不懂得独立思考的缺乏正确评价标准的人们脱离了工程哲学，去追求很多华而不实的东西。
当然，搬砖做业务，用很多语言都可以搞定都可以拿工资挣钱养家糊口甚至发财飞黄腾达，但这些不合理的评价方式，把好和不好的舆论带偏了，舆论偏了、但是好和不好的实质却不会变。
可以有很多人继续这些不承认 Go 的优秀、看不上甚至贬低嘲讽 Go ，但也应该有我们这些所谓的 Go 邪教信徒的仗义执言为 Go 说说公道话，况且，谁是邪教信徒不是张嘴闭嘴说别人邪教的人决定的，真理掌握在少数人手中是常有的事。

> 提契合度不等于忽视优点，而是划分决定性因素和非决定性因素。不然人家 C# 用户要问了，C# 也很优秀，为什么不选自家产品？

@Nugine0 这点我是理解的，我也知道契合度是最重要原因之一，但是这些对契合度的“客观评价”，例如“选 Go 不是因为 Go 多优秀”、“是为了 port 、选 Go 是因为 Go 和原来的代码像”这些措辞方式，几乎都会给其他人带来一种 Go 不优秀的错觉。
如果是我，我可能会说：首先，Go 在几个方面都比较优秀、都能够达到这个选型的要求，并且在此基础之上，相比于其他语言 Go 是契合度最高的。

> 选择的核心不在于 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