看到今天群里有人讨论微软用 Go 重写 TypeScript 编译器,为什么不是用他们自家的 C#? C#在大部分 benchmark 项中性能都远超 Go, TypeScript 编译也不是在浏览器进行,不用考虑编译器体积

2025 年 3 月 12 日
 drymonfidelia
C# 性能远超 Go 来源

https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fannkuchredux.html
以及这个网站的大部分项目

别的 benchmark 网站结果也大致相同

另外 C#和 TS 大部分类型都对应,实在找不到要用 Go 的理由
14505 次点击
所在节点    程序员
115 条回复
Nugine0
2025 年 3 月 13 日
@lesismal #77
你不能按“没说优秀就是否定优秀”来判定,或者对“不懂得独立思考”的人的影响来判定,不然每次写回复都得叠
甲,很累……
该用 go 的时候我也会用,但体验到 go 的众多拍脑袋设计之后,也确实说不出口它有多优秀,只能说是个实用语言。
再加上社区提案爱答不理,谷歌需求立马安排,这种行为实在是难绷,可能需要微软出个 go# 给他们上上压力。
lesismal
2025 年 3 月 13 日
> 你不能按“没说优秀就是否定优秀”来判定

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

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

这个是事实,而且不只是编程领域
tt0411
2025 年 3 月 13 日
其实在我看来, 最重要的一个原因是, golang 生成的可执行文件是 self-contained (在大部分操作系统里面只对 c runtime 有依赖; 现代操作系统应该没有不带 c runtime 的, 因而可以视为没有依赖), 是最容易分发的, 迁移阻力是最小的.

用 C# 就必须带 dotnet runtime 或者 ART; 但是这个 dotnet runtime 或者 ART 能覆盖多少 os/arch 还真不好说; 要知道现在 x86/arm 之外的 arch 有上升的趋势; 而 golang 这块从他诞生开始, 就做得比较好;

至于很多说的语法层面的事... compiler 本身的代码是没有太多魔法的, 一般写起来也都是常规语法.
Nugine0
2025 年 3 月 13 日
@lesismal #82
那我只能说,批判别人“没说优秀”的行为只会把别人推向反面了。
优不优秀是主观看法,不符合我的需要和审美,就是不优秀。这是没法客观论证的。
能客观论证的是哪些方便做,哪些可以做,哪些做不了。
lesismal
2025 年 3 月 13 日
@Nugine0

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

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

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

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

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


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

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

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


另外,很多人评价编程语言都有点脱离实际了,脱离工程实践:用设计和实现编程语言本身的标准去评价一个编程语言,脱离了绝大多数人使用编程语言是用于工程实践的实际情况。
比如:那些编程语言设计的相关理论,比如高级语法糖要比性能 N 倍的提升更好。
当然,如果项目本身对简洁没有要求,对性能没有要求,对工程管理没有要求,对很多都没有要求,随便找个什么模板或者老代码改改就能跑,都很高效率,如果都是按照这种出发点,我说的 Go 的优点也好缺点也好就都没意义了。
stabc
2025 年 3 月 13 日
我认为 Go 最大的确定就是强加给使用者一些怪癖,比如 switch..case 之间没有缩进
lesismal
2025 年 3 月 13 日
@Nugine0

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

自己具有一定水平和判断力的人,也不会因为别人的态度就站在了反面
uni
2025 年 3 月 13 日
oop 应该要被扔进历史的垃圾堆了
zhjunjun
2025 年 3 月 13 日
c#之父都不用 c#,各位破防不~
Nugine0
2025 年 3 月 13 日
@lesismal #85

> 客观的 gopher 就是这样做的,包括我自己
我并不认为要求别人给出“优秀”的评价是一种客观的做法。

> 自己具有一定水平和判断力的人,也不会因为别人的态度就站在了反面
本来给出正面评价、想避免引战的人,现在会附带一些个人看法。

1. Go 至今没有官方的全功能版本管理器,升级工具链得手动来或者借助第三方工具。
2. unused import 是 error 不是 warning ,想注释掉某些使用看看效果,还得跟着改 import 。
3. "nil" 不是 nil 。
4. 默认零值,零值和空值的区分问题。
5. 大小写访问控制,导致结构体序列化要为每个字段写 json 重命名。
6. 时间格式串 "2006-01-02 15:04:05",最迷惑的设计之一。
7. 缺少 enum 导致 switch case 无法检查有没有覆盖所有情况。
8. 循环中使用 defer 。

你也不用告诉我解法,这些坑我都知道。只是想说,在体验过这些后实在是不能称其为“优秀”。
Manweill
2025 年 3 月 13 日
都认真去看看原文吧,选 go ,不是因为他多优秀,而是他在迁移这个工作上最合适,能符合 tsc 编译器这个工具的需求。带 gc 、函数式编程、内存共享的并发、以及足够低级的语言。不要总是自 high ,选合适的语言做合适的事情才是最合理。
Manweill
2025 年 3 月 13 日
godspeedyou
2025 年 3 月 13 日
不是太懂楼上很多人一直在强调“不是因为 go 优秀”,如果 Anders Hejlsberg 选择了 go ,是不是说明在这个场景下 go 足够优秀呢
lesismal
2025 年 3 月 13 日
@Nugine0

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


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

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


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

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


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

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

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

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

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

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

不要只觉得喜欢 Go 的人是在自 high ,无脑黑 Go 和不屑承认 Go 优点优秀的人难道不是自 high 吗?
无脑否定 Go 的人不只是自 high ,而且还很不喜欢务实的事物,不知道有什么可出来炫耀的
liuliuliuliu
2025 年 3 月 13 日
不是,为什么这么多人还在说 .net 要带运行时啊?
aot 出来几年了,现在.net 可以原生编译,不需要带运行时了
lesismal
2025 年 3 月 13 日
@godspeedyou
#93 国人爱谦虚,很多事情都会谦虚,比如自己拿了什么冠军还是要说“我还有很多可以提高的地方”。但这个案例里,他们都不是谦虚了,就是不愿意承认 Go 的好。
说好听点是他们懂得多,说不好听点就是很多人喜欢踩一脚来变相抬高自己。
mooyo
2025 年 3 月 13 日
@liuliuliuliu .NET 的 AOT 到现在都还是一坨。。一堆官方库都还没完全 AOT 化
Nugine0
2025 年 3 月 13 日
@lesismal #94
> at 你是因为 #63 说资历的问题

那我明确一下,#63 是指向 #60 。无意冒犯你。

> 如果因为我的观点就导致了你带个人看法,那我表示抱歉
> 但我建议不要这样、这相当于丢掉了自己的理性判断,没必要

在别的评论区我还是会保持避免引战,给出什么语言适合什么场景的评价,而不会一概而论哪个语言就是优秀。
即便有人说 rust 有什么问题,只要客观存在,我也会同意。
Go 1.0 已经 13 年了,不能论质量就是成熟,论问题就是年轻。

> 严格来讲不是否定,但在宽泛的社交语境,这约等于否定、并且实际效果就是偏否定的
> 我没有要求任何人给出优秀评价,而是反驳这些人,为什么如此了还不能称为优秀。

没说优秀=否定优秀=需要反驳,我觉得你不需要坚持这个链条去反驳任何人。
讲一讲 Go 的相对优势适用于哪些场景,分享你自己的实际经验,已经足够了。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://v2ex.ih06.com/t/1117872

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX