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

我不知道这是不是你工作中同事在做的事情，我觉得大概分两种：
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 麻烦些，甚至以前没有范型、要为不同类型都写几个相同实现，但这些多数归属于简单的逻辑、稍微花点时间就可以搞定了，并没有真正消耗开发效率。

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

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


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

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

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

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

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

虽然能反映出很多框架的性能，但 techempower 也是我见过最逗比的没底线的 benchmark 之一了，plaintext 里包括 gnet 、evio 这种不完整 http 功能的简单拼接字符串方式的测试代码也可以放到排名结果里，甚至这种能拿个 plaintext 第一至今还贴在这种 repo 仓库里作为宣传工具误导不知情的同行。而且这样一来，助长了更多的不良之风：
https://github.com/lesismal/nbio/issues/337#issuecomment-1663771688


go 的 cpu 能力和 java 是差不多的，这种简单测试的结果不意外。

帖子里一些人觉得 gin 简单，是一种错觉、简单与复杂对比错了层面：
1. 在这个简单 http 功能测试对比 gin 和 spring 性能的场景，应该是看 http 基础部分实现的性能复杂度。单就 http 相关的实现，gin 等 go 框架在性能消耗上的浪费可能比 spring 还多，所以 fast 系能赢、gin 和其他几个基于标准库的难赢
2. 各位对比的简单是作为 http 框架甚至框架生态圈的大的功能集合的简单与复杂、但是这部分与这个性能测试是没什么关系的

实际工程中高并发场景，影响性能的重要因素之一是并发度，主要是连接数、协程池｜线程池。
java 非 netty 通常的业务线程池 size 设置不会特别大，几百几千，如果遇到并发很大并且一些请求阻塞时间较长时，这些阻塞时间长的请求会持续占用线程，线程池 size 小、等待得多了甚至整个线程池的 worker 都阻塞、临时耗尽了，其他连接的请求要排队，cpu 利用率就跑不上去、业务慢了。
go 这种协程成本低，即使时 4c8g 这种硬件，随便也可以跑几万甚至 10w 级别的协程数量，对应的能服务的连接数就更多，所以部分连接的请求即使阻塞了、处理其他大部分连接的协程就被调度起来继续运行了、cpu 不用等待，因为几万甚至 10w 级别的协程数量远大于 response write 这些 syscall 、远大于下游的 db 操作、或者其他 io 等慢阻塞的并发度，所以整体上不会导致 cpu 利用率降低。

我没有仔细研究这个测试，但没有找到实际测试的连接数并发度，也没有看到各个语言框架对应的 cpu 、内存消耗。
不同的参数会有不同的阈值，如果只是一组参数测试得出结论，不能够准确说明实际业务中不同场景不同时段等的真实性能表现。

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

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

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

@Nugine0 #106 继续

而且，很多人无脑黑 Go 的，比如看到 nbio 搞百万连接优化，想都不想就会出来喷、说官方都可以写同步代码、你非要搞个异步非阻塞库这是倒退，但其实 nbio 对标准库是基本兼容的、使用方法还是用标准库那样的方式仍然是写同步代码；
还有些人一看 nbio 名字里的 nb 就开始“国人的项目净搞噱头”，实际效用他们可不管，张嘴就是嘲讽、阴阳。

这也是为什么我看到很多黑 Go 的或者对 Go 负面影响的评价会经常站出来反驳的原因，因为自己就被他们无脑黑或者嘲讽过很多次了

@Nugine0
我的开源项目已经发过几次帖子了，发多了也会惹人烦，而且论坛的流量也不大了，所以就很少发了。
一些优化的点倒是可以拿来说说，但是这些点我觉得都挺平常的，比如海量连接数、协程池、内存、gc 、网络哭、rpc 性能各种优化和实现策略，以前跟很多人讨论过很多次了，github repo 的 issue 里也有不少相关的都在。
最重要的，比如 nbio 是为了解决标准库海量连接数场景的弱项、1M 连接数 1k payload echo 压测 server 内存可以控在 1G 内存、4-8c 能跑 10w+ qps ，但绝大多数人用不到，绝大多数人的场景连接数都不高、用标准库足够了，少量的人用得到的自然可以找上门来；至于 rpc ，我自己的 arpc 性能和易用性里都算是 top 了，但更多人就是喜欢 grpc 、毕竟跨语言和整体生态更强谷歌背书，而且多数人是 web 领域微服务之类的、普通 rpc 也足够用了，少有人懂更多的才会考虑用 arpc 去做更多业务类型比如游戏、IM 、推送而且顺便性能提升一大截。
我个人也没那么多精力去搞更大，为爱发电成本太高了。所以也懒得去宣传这些了，有缘的人多交流就可以了

@Nugine0 #102

文人相轻，同行相轻，编程语言里的踩踏更是如此，尤其是 Go 这种定位务实不搞花哨的。
这些都是人性，我自己飘了的时候也要乱讲、毕竟不是圣人，无所谓羞愧，对了就坚持错了就承认和改变。
人性的事情确实改变不了，但是互相喷下也没啥，不想让 Go 和 Gopher 吃哑巴亏。

> 没说优秀=否定优秀=需要反驳，我觉得你不需要坚持这个链条去反驳任何人。

@Nugine0 通常没有出来反驳的必要，但是这种“不是因为 Go 多优秀”的实际效果就是“Go 不优秀”，让人挺无奈的

@godspeedyou
#93 国人爱谦虚，很多事情都会谦虚，比如自己拿了什么冠军还是要说“我还有很多可以提高的地方”。但这个案例里，他们都不是谦虚了，就是不愿意承认 Go 的好。
说好听点是他们懂得多，说不好听点就是很多人喜欢踩一脚来变相抬高自己。

@Manweill #91 是的，所以选型了一个性能给力、自带 gc 省力开发效率高、并发极大便利、底层能力、函数方式编程个方面都适合，但只要不是嘴上承认这些点都算优秀，就不是 Go 多优秀，因为别的多种语言也都分别有这些对吧？
即使别人选型 Go 了并且说明了为什么 Go 在多个方面都很适合、适合也不是因为优秀，只是因为适合，即使脱离了这个 case 本身也不用考虑 Go 本身、Go 本身就不是多优秀对吧？佩服你们的推理能力。
最适合的候选人，即使不说他多优秀也就算了，一个个的都站出来说不是因为他多优秀、不带任何至少它满足了个方面需要的前置条件，这不就是在那不屑地假装理中客地暗黑吗？

不要只觉得喜欢 Go 的人是在自 high ，无脑黑 Go 和不屑承认 Go 优点优秀的人难道不是自 high 吗？
无脑否定 Go 的人不只是自 high ，而且还很不喜欢务实的事物，不知道有什么可出来炫耀的

@Nugine0

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

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

都这样了还不算优秀，那么多人对不优秀的评价就客观吗？
别人认为这种不客观、所以反驳就是不客观吗？

@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 本身的这些优点的前置条件视而不见