看到今天群里有人讨论微软用 Go 重写 TypeScript 编译器，为什么不是用他们自家的 C#？ C#在大部分 benchmark 项中性能都远超 Go， TypeScript 编译也不是在浏览器进行，不用考虑编译器体积
drymonfidelia · 14 天前 · 8939 次点击C# 性能远超 Go 来源
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fannkuchredux.html
以及这个网站的大部分项目
别的 benchmark 网站结果也大致相同
另外 C#和 TS 大部分类型都对应，实在找不到要用 Go 的理由
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fannkuchredux.html
以及这个网站的大部分项目
别的 benchmark 网站结果也大致相同
另外 C#和 TS 大部分类型都对应，实在找不到要用 Go 的理由
115 条回复 • 2025-03-14 17:05:47 +08:00
 |
1
iyiluo 14 天前  1
go 可移植性好
|
 |
2
drymonfidelia OP |
|
4
drymonfidelia OP @cyp0633 我看过这个讨论串了，只提了 a bit of a vote of no confidence in C# 没有提具体的原因
|
 |
5
guotie 14 天前
他说了，C#更面向对象，js/ts 跟 go 更接近，更好 1:1 移植
|
 |
6
stimw 14 天前 via Android 1
|
|
7
stimw 14 天前 via Android
@drymonfidelia 具体原因楼层我已经发了
|
 |
8
cyp0633 14 天前 2
@drymonfidelia #4 &t=1154s
|
 |
9
k9982874 14 天前 via Android 3
|
 |
10
DTCPSS 14 天前
C# 设计上是字节码优先的，虽然有 AOT 但是缺少实战检验，而且最初也不是为这类场景设计的，有些环境会有问题。
Go 的代码组织方式和现有的代码更相近（函数 + 数据结构，非 OOP ），方便一比一翻译。 |
|
11
drymonfidelia OP @k9982874 我挺希望这样，现在 C#的跨平台 UI 框架没一个完善的，如果微软能让 C#上 Rank #1 我觉得这个问题能被改善
|
 |
12
Hellert 14 天前
人家明确说了是移植，不是重写。单就这一点来说，C#是面向对象的，就不合适。
|
|
13
drymonfidelia OP @Hellert 如果单纯是这个原因的话，面向对象的语言也可以不使用和对象相关的特性
|
|
14
k9982874 14 天前 via Android
@drymonfidelia 别闹，现在 node_modules 已经够地狱了，.net 再拖家带口住进来，nodejs 就不能要了
|
 |
16
sagaxu 14 天前 3
他们是 port ，不是 rewrite 。用 Go 可以很简单的按文件翻译，代码长差不多。
 如果用 C#，为了高性能，就要大量使用 Span<T>和 Memory<T> ，那 port 工作量就太大了。C#的优势，模式匹配和异常处理，不擦除的泛型等等，都完全用不到，aot 编译耗时比 Go 长很多倍，得不偿失。 |
 |
17
TanKuku 14 天前 2
因为 LOGO 都是蓝色的
|
 |
18
idealhs 14 天前
我才知道有的语言编译器是不自举的
|
 |
19
lesismal 13 天前 10
看到过好多次说 C#比 Go 好的了，希望这个事情让你门清醒。。。
BTW ，这事情里的函数式不是通常说的函数式编程 函数式太多花活、隐藏机制、性能浪费，不是什么好玩意 OO 太多累赘、啥都得 class 、顶层设计难以预计未来、难以高效应对快速变化，不如面向过程更加通用 Go 很务实，有的人认为他平庸，简洁、甚至 N 倍性能提升都进不了这些认为 Go 平庸的人的“法眼”，反过来还要喷“大道至简”，我无法对这些人的智力水平作出评价，因为我不想贬低别人但也更不想撒谎。 |
 |
22
InkStone 13 天前
@lesismal 我想主楼已经说得很清楚了，选用 Go 不是因为 Go 多好，而是因为 Go 最像 Javascript 。
基于这个案例，你其实可以把“Go 是否是一门设计优秀的语言”这个问题近似转换成：“Javascript 是一门设计很优秀的语言吗？” 我想后者比前者的争议小多了。 |
 |
23
redbule 13 天前
@lesismal C#最大的问题就是当年抄了 JAVA 的 oop ，整了一套复杂累赘的继承系统。后面发现路子歪了，疯狂打补丁，语法糖一个接一个，但已经逃不出 oop 的框子了。注定和简单无缘。
|
|
26
redbule 13 天前
@InkStone 按你这个逻辑。js 有多种范式的写法。那么问题来了，为什么 tsc 的写法要像 go 呢？它也可以像 C#和 java 一样用 oop 写。是不是可以说 oop 就是不行呢。
|
 |
27
Mexion 13 天前 via Android
@redbule 因为直接代码转换过来简单，TS 编译器很少用到类的写法，函数式写法比较多，用 Go 可以直接改一下关键字和少量语法就转过来，如果用 OOP 写法差异太大改动就太大了。简而言之，TS 的开发团队不想花太多时间和精力在代码转换这件事上。
|
 |
29
ambition117 13 天前 1
负责这个项目的是 c#之父，c#之父也不用 c#，破防不？
|
 |
30
qxmqh 13 天前
go 简单啊，不用面向对象，基本没有类这个概念，结构体 +interface 能完成 90%以上的任务，编译又快，内存占用又小，天生支持高并发，这些是个人都知道的，有啥可奇怪的。
|
 |
31
csys 13 天前
最直接的原因就是 go 足够“原始”
C#是高度抽象的语言，可移植性很差的，java 同理 这是个很简单的哲学命题 |
|
32
lesismal 13 天前
> 我想主楼已经说得很清楚了，选用 Go 不是因为 Go 多好，而是因为 Go 最像 Javascript
@InkStone #22 得出这样的结论，我大概也懂了为啥你们认为 Go 平庸——Go 的优点一点都看不到或者不承认 只能建议看下隔壁帖子了： /t/1117764 你们认为 Go 平庸就认为吧，#19 里我已经说过了 |
|
34
lesismal 13 天前 1
@redbule 是的，所有天生 OOP 以 Class 为主要模式的，都有这个毛病，十多年前没有这么高速发展的 IT 互联网的时代，还好，时代变了之后，业务种类和规模越来越大了，需求迭代越来越快了，OOP 尾大不掉、顶层设计难度和开发效率拉垮。所以很多独角兽在没有历史包袱的领域大量用 Go 从头造甚至抛弃旧的技术栈用 Go 大量重构，国内一些明星企业做了太多这种示范了，但就是有很多人看不懂、无脑喷 Go
|
 |
35
zhangqwesc0 13 天前
这个 benchmark 里面，排除掉*开头的"safe"实现里面，go 不是仅次于 c/c++和 rust 吗
|
|
37
lesismal 13 天前
@InkStone #33
你可以看下隔壁#12 的总结，前面几条可都不是因为 Go 跟 JS 像，用 Go 重写 TS 编译器也不是因为 Go 像、重写 TS 编译器本身的目的是在于提升 TS 编译器的性能和体验。 要说像那还是 TS 自己跟自己最"像"、本来就是自举何必要换语言重写呢？ 所以，得出 Go 和 JS 像是原因这种结论，可能是因为自己对 Go 的刻板印象、首先默认 Go 不行、然后拿着结论去找原因，本末倒置了、推导的方法不对、第一步就错了 |
|
38
InkStone 13 天前
@lesismal 事实上，里面提到的 Go 的优点就是一条：并发编程支持好。
其它的都只能说是“特点”。比如本身支持底层操作（底层语言不支持底层操作这像话吗？），有 GC ，编程范式和 tsc 原有的实现方式接近等等。 当然，真说起来，说 JS 和 Go 像确实也没那么贴近事实，更贴近事实的是：Go 和 tsc 里使用的那一部分 ts 语法子集（接近于带 typehint 、不怎么玩 prototype 等花活的 js ）很像。 你喜欢 Go 的心情我能理解，但自始至终你都没说出什么 Go 什么优点来，这实在有点难绷…… |
 |
40
rarpainting 13 天前
有没有人上 github 提个 issue 问下
|
|
41
lesismal 13 天前 2
@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 各种，好和不好都是亲身体验和总结，不是站队性质也不是跟风性质的观点输出 |
|
42
InkStone 13 天前
@lesismal
> 支持和好用是两码事 这就是为什么我说 Go 支持底层操作之类的只是特点而不是优点。 Go 的底层操作并算不上很好用，性能也有很大优化空间。我知道它是权衡利弊之后做成这样子，但在编译器这个领域，它在权衡中舍弃的那些东西还是挺重要的。 Go 的缺点大家都说过很多了我也懒得说了……现在不是别人没正视 Go 的优点，而是你没正视 Go 的缺点。 |
|
43
lesismal 13 天前 1
@InkStone
很多人因为自己学过什么，就会有什么的思维惯性，然后对其他的异类事物会有抵触，尤其是如果自己所学的东西看上去更加复杂、先进，比如花样多、语法糖多、语言理论现代化，看上去好像很高级，就会反对看上去更加低级的比如 Go 。 经济学上相当于沉没成本效应，心理学上大概叫首次效应，玄学上这叫迷了眼 真正成为语言邪教的是这种人，而不是抛开这些花哨、踏实从工程角度去考虑工程实践的实用主义的人，谷歌早期宣传的时候的定位，就是这种工程实践的实用主义哲学、以及很多人眼中所谓的和嘴上黑化了的"大道至简"，只顾皇帝的新衣不看内里，是做不好实事求是的。 |
|
44
InkStone 13 天前
|
|
45
lesismal 13 天前
@InkStone #42
> 这就是为什么我说 Go 支持底层操作之类的只是特点而不是优点。 我甚至都没理解，你说的底层操作这些跟这个帖子本身提到的重写 TS 编译器有什么关系，重写 TS 编译器这个用到的 Go 的好像都是基础部分、不涉及底层吧，如果是说没有字节码、语言性能以及并发便利和性能本身这些都与用 Go 底层没什么关系的。。。 如果抛开这个帖子谈底层，绝大多数搬砖的都不需要用到 Go 底层，Go 为了方便大家提供了优秀的标准库已经非常大地解放大家的生产力了。。。 而至于真正需要搞底层的，又有哪个语言的底层是好用的呢？除了 c/c++因为系统就提供 c 接口、其他语言的底层也没怎么好用，但是 c/c++除了跟系统亲近、做应用层的效率也太拉了，所以也完全没必要用来对比。。。 > Go 的缺点大家都说过很多了我也懒得说了……现在不是别人没正视 Go 的优点，而是你没正视 Go 的缺点。 很多人所说的 Go 的缺点，恰恰是优点。Go 的一些缺点我知道，但是瑕不掩瑜。哪个语言没缺点呢？但是哪个其他语言的缺点少而且优点又像 Go 这么大呢？ 鼓吹 Go 这不行那不行的人们，多数是我#43 说的这种，一叶障目罢了 |
|
46
lesismal 13 天前
@InkStone #44
我这可都是实事求是啊，不像你们直接说我因为喜欢 Go 而怎样。。。#43 这种我分析的也是多年来看各种技术讨论对这类人和现象原因分析的总结啊，相信我，琢磨一下，可以大大提高自身境界。。。 |
|
47
lesismal 13 天前
> 难道你以为就你一个人写过十几门语言么？对能独当一面的开发者来说，这都是最基本的好吧。
@InkStone 我这个是用来反驳你说我因为喜欢 Go 、说明我是实事求是的，并不是自吹，也不是假设你们其他人不懂多门语言。但既然也都搞过那么多，还能得出这样的结论，确实就是#37 这种本末倒置了，造成这种情况，可以认真考虑下#43 、然后优化优化知识结构。。。 |
|
48
InkStone 13 天前
@lesismal
> 底层的问题 底层部分是原文内容。开发者特别强调了他需要 Go 的底层能力——事实上性能提升也多半来自于此。把工程从高抽象层次的实现改到 native 语言，天然就会获得巨大幅度的性能提升。 > 但是哪个其他语言的缺点少而且优点又像 Go 这么大呢？ Go 的优点在各种语言中并不算特别突出，缺点比 Go 少的语言更是数不胜数。 如果你非要我提一门这样的语言出来，那底层语言我提名 C ，几乎完美无缺的语言，它在整个编程体系重要到它的缺点都不再是缺点。 |
 |
49
thinkershare 13 天前
要吵架可用去这里
https://github.com/microsoft/typescript-go/discussions/411#discussioncomment-12467996 微软给出来的理由在我看来是站不住脚的，除了他们想要偷懒，不想完全重写。 |
|
50
lesismal 13 天前
@InkStone
以往的技术帖子也都一样，除了偶尔插科打诨，技术问题我都是尽量实际出发的，讨论的点都是带着实际内容的。。。 所以遇到很多类似这个帖子里的情况： 1. 根据采访内容能得出因为 Go 和 Js 像是用 Go 的主因。。。 2. 我用事实论证能推出我是因为喜欢 Go 。。 3. 我用自己的亲身体验论证不是因为我喜欢 Go 而说 Go 好，被推论出我是在炫耀自己会得多。。。 我也是挺诧异的，到底如何实事求是地讨论技术问题 |
 |
51
mahaoqu 13 天前
Go 和 TS 一样都使用名义类型应该算是最大的类似之处了，其他所有主流语言都不支持这一特性。
|
|
52
lesismal 13 天前
@InkStone #48
> 底层部分是原文内容。开发者特别强调了他需要 Go 的底层能力——事实上性能提升也多半来自于此。把工程从高抽象层次的实现改到 native 语言，天然就会获得巨大幅度的性能提升。 这些底层能力是只要你用 Go 就有了，并不需要你特殊去使用底层怎样。你前面#42 说的是：Go 的底层操作并算不上很好用。 Go 本身的底层能力天然获得大幅提升，和你说的底层操作算不上好用，没关系吧，所以你后面的解释，和自己的观点都对不上、和我反驳你前面的点也是对不上的 > Go 的优点在各种语言中并不算特别突出，缺点比 Go 少的语言更是数不胜数。 这个#19 我已经说过了：Go 很务实，有的人认为他平庸，简洁、甚至 N 倍性能提升都进不了这些认为 Go 平庸的人的“法眼”。 采访里的大佬也说了的： “你必须明白，Go 在设计上是平庸的；它并不想花哨。” Anders: 它试图成为一种简单的语言——说实话，确实如此。但结果并不平庸。我的意思是，10 倍，这完全不平庸，对吧？所以，你可以用这个东西做伟大的事情。 但我能猜到、这种大佬也是入不了认为 Go 平庸的人的“法眼”的。所以咱们争论是没什么意义的，你们说服不了我，我也说服不了装睡（或者其实是达不到装睡水平）的人 |
 |
53
crackidz 13 天前 1
Anders Hejlsberg 的技术决策真的适合所有人看一下，其实很说明技术选项的考量，尤其是现有仓库的迁移
当然，很多显示情况下，自己遇到项目时，更多会是政治性的或者党争了...而且作为 Pascal 专家 / C# 首席架构师和设计者之一，肯定是充分考虑了多重因素，比如他也提到尝试过 C# 的工作（并且已经可以运行了），但是最终发现并不合适 |
 |
54
Nugine0 13 天前
人家想找个能支持 typescript 旧代码库风格的原生语言，把逻辑原原本本地**移植**过去，选 Go 很正常。
如果要彻底**重写**所有架构，人家说了，用其他语言也合适。而且未必达不到 Go 的性能。 根据任务目标进行决策没什么毛病，想参考的话，看看你的任务目标是否一样。 |
|
55
crackidz 13 天前
另外，Anders Hejlsberg 的回复里也反映了微软自身在开源社区的转身，这可以作为微软封闭生态到逐步开放的一个缩影。当然，过去几年微软其实一直在做出改变。往前十年，你甚至无法想象现在的微软
|
 |
56
kiwi95 13 天前
@thinkershare #49 这样的工程完全重写 90%的概率完成不了，就算完成了，还有可能 90%功能不全或者 break 原来的逻辑，并且完成之后新旧两版都要维护的，不可能旧版本就扔了不要了吧，一个 patch 怎么在两个版本都能应用也是非常困难的，这不是偷懒，而是务实。
|
 |
57
sunshower 13 天前
要是用 C#，大家岂不是又要骂微软封闭了
哪个有好处用哪个，不是挺好的 |
 |
58
leokun 13 天前 8
 |
|
59
thinkershare 13 天前
|
 |
60
dbskcnc 13 天前 2
以 Anders Hejlsberg 的资历，在座的大概给人家提鞋的资格都没有，就不要指点江山，大放厥词了。
|
 |
61
willchen 13 天前
开源角度来讲 go 的社区比 c# 应该还是好点的
|
|
62
sagaxu 13 天前
@nziu 选择的核心不在于 Go 有多优秀，而是契合度，在同等性能的这个梯队中，没有比 Go 更合适的了。tier2 的性能 + 简洁的并发设施 + 带 GC 的类 C 语法 + tier1 的交叉编译能力，从这几个维度去考虑 Go 的契合度就是第一的，这是从工程角度去衡量，而不是语言设计。
Rust 很优秀，但为什么进 Linux 内核阻力重重？是 Linus 等大佬学不会吗？大概率还是工程问题，而非技术本身的问题。 |
|
63
Nugine0 13 天前 via Android
资历只能影响一个人说话的份量，但不会自动堵上别人的嘴，望周知
|
 |
65
weiwenhao 13 天前
typescript 编译器的主要功能就是编译为 javascript 吧。相当于是文本转换的功能，用 python 写都无可厚非，也就是编译速度快慢。
不太了解 c# 的跨平台交叉怎么样，是否方便，选择 golang 一般是看重了 golang 的 auto gc(对于编译器这种一次性应用，内存没啥用), 超级方便且独立跨平台编译特性(不需要 llvm)，语法也足够简单, 现在 golang 的现在的运行速度也足够优秀，即使是 cpu 密集应用，性能上不会比 rust 逊色多少。 当然我觉得如果 rust 重构应该会带来更加极致的 ts 编译为 js 的编译器速度。 |
 |
66
DrakeXiang 13 天前 1
原贴说得挺明白了，https://github.com/microsoft/typescript-go/discussions/410 这个贴也说明了为什么是移植不是重写，简单来说就是 go 和现有的代码最像，能 1:1 移植，能减少产生出的新问题，甚至要保留现有代码的 quirks 以实现最大的兼容性，同时还能在后续同时维护的时候两边都能快速修改
|
 |
67
levelworm 13 天前 via Android
感觉 js/ts 成为世界上应用最广泛的语言之一，也是命运。说实话完全不喜欢前端开发。
|
|
68
lesismal 13 天前 1
> 选择的核心不在于 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 本身的这些优点的前置条件视而不见 |
 |
69
hguangzhen 13 天前
dotnet 从业者，看到新闻天都塌了。 准备转 go 了
|
|
70
qxmqh 13 天前
@hguangzhen 转吧，go 绝对是未来的王者。现在已经稳稳在前十了，未来前五大有希望。
|
 |
71
jiazhoulvke 13 天前 6
C#布道者：臣等正欲死战，陛下何故先降？
|
|
73
sagaxu 13 天前
@lesismal 68# 优秀不是一枝独秀，如果这次不是移植，是彻底重写或者给新语言写编译器，我觉得未必会选 Go 。前端工具生态圈，选择 Rust 的也相当多，例如 swc/oxc/rspack/rolldown/parcel 2 。
|
 |
74
laminux29 13 天前
C# 是我用过最强的语言，超越 C 、C++、Java 、PHP 、js 、Python 。它能同时拥有 C 、C++ 的强类型与 js 、Python 的弱类型，性能也很好。
但 C# 因为强绑定了 Windows ，早期不开源，导致错失了发展机会。 |
|
75
qxmqh 13 天前 1
早在 1998 年法国世界杯的主题曲《 The Cup of Life 》中就决定 go 的地位了，Go Go Go! Ole Ole Ole!
|
|
76
Nugine0 13 天前
@lesismal #68
所谓 Go 是优秀还是平庸，一般是从语言设计的角度衡量。而 Go 在语言特性上有意取舍，有人称之为简洁，有人称之为简陋，可以找到大量相关评价，甚至长年累月的“语言战”。 Go 并不完美，在语言特性和工程实践上也有不少坑。隔壁刚好有人提问 https://v2ex.com/t/1117750 ，作为一个新鲜例子。 引用官方回复 > No single language is perfect for every task TS 团队官方的意思也是以契合度为主要原因，前面提的优点是契合度的论据。换一个任务场景就不一定是优点了，例如不可能拿 Go 去重写 LLVM 。而且 Go 的进程内 JS 互操作性和 WASM 支持也是很多人提出的疑问。 提契合度不等于忽视优点，而是划分决定性因素和非决定性因素。不然人家 C# 用户要问了，C# 也很优秀，为什么不选自家产品？ 最后叠甲，以上仅为个人对此事的看法，不代表任何选型意见，无意冒犯任何人。 |
|
77
lesismal 13 天前
@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 是契合度最高的。 |
|
78
lesismal 13 天前
|
|
79
lesismal 13 天前
1. 性能很好，但是：性能不是 Top ，所以不是它优秀；
2. native 并且带 gc ，既有性能又不需要为内存管理太操心，但是：其他一些语言虽然没有 gc 但也是 native ，其他一些语言 3. 虽然不是 native 但是也有 gc ，所以不是它优秀； 4. 跨平台支持够好，但是：其他语言虽然性能可能不那么好而且字节码，但也有跨平台够好的，所以它不是优秀； 5. 语法简洁特性少，很明显：缺少高级特性，不够现代化，“大道至简”就是笑话，所以它不是优秀； 最方便易用的并发，但是：其他语言也有并发，虽然用起来麻烦点或者性能不够好，但反正别的语言也有，所以它不优秀； 。。。 我真想知道，什么才能被称为优秀。 |
 |
80
june4 13 天前
很正常合理的选择，要不是作者本身是 c# 作者，rust/go 里选一个本来毫无波澜是大家默认的选择，基本没人会考虑 c#。
只能说 c# 不是全能，不但语言设计臃肿 还带个同样臃肿的 .net 运行时，只能和 java 类比了。 |
|
81
Nugine0 13 天前
@lesismal #77
你不能按“没说优秀就是否定优秀”来判定，或者对“不懂得独立思考”的人的影响来判定，不然每次写回复都得叠 甲，很累…… 该用 go 的时候我也会用，但体验到 go 的众多拍脑袋设计之后，也确实说不出口它有多优秀，只能说是个实用语言。 再加上社区提案爱答不理，谷歌需求立马安排，这种行为实在是难绷，可能需要微软出个 go# 给他们上上压力。 |
|
82
lesismal 13 天前
> 你不能按“没说优秀就是否定优秀”来判定
@Nugine0 严格来讲不是否定，但在宽泛的社交语境，这约等于否定、并且实际效果就是偏否定的 > 或者对“不懂得独立思考”的人的影响来判定 这个是事实，而且不只是编程领域 |
 |
83
tt0411 13 天前
其实在我看来, 最重要的一个原因是, golang 生成的可执行文件是 self-contained (在大部分操作系统里面只对 c runtime 有依赖; 现代操作系统应该没有不带 c runtime 的, 因而可以视为没有依赖), 是最容易分发的, 迁移阻力是最小的.
用 C# 就必须带 dotnet runtime 或者 ART; 但是这个 dotnet runtime 或者 ART 能覆盖多少 os/arch 还真不好说; 要知道现在 x86/arm 之外的 arch 有上升的趋势; 而 golang 这块从他诞生开始, 就做得比较好; 至于很多说的语法层面的事... compiler 本身的代码是没有太多魔法的, 一般写起来也都是常规语法. |
|
84
Nugine0 13 天前
@lesismal #82
那我只能说，批判别人“没说优秀”的行为只会把别人推向反面了。 优不优秀是主观看法，不符合我的需要和审美，就是不优秀。这是没法客观论证的。 能客观论证的是哪些方便做，哪些可以做，哪些做不了。 |
|
85
lesismal 13 天前
@Nugine0
> 那我只能说，批判别人“没说优秀”的行为只会把别人推向反面了。 本来就能自己判断和认同的，不需要去劝导加入； 本来就不觉得它优秀的、也没站在它这边、而且所谓的客观评价造成的效果其实就是反面。如果没人出来说明，只会让更多人站在反面，所以总不能因噎废食、只让反面效果的事情野蛮生长吧？ > 优不优秀是主观看法，不符合我的需要和审美，就是不优秀。这是没法客观论证的。 每个人有自己的主观，我和其他人也没有强求去改变单个人，但是要澄清各自的观点，避免造成反面效果的客观评价称为主流 很多人开始用 Go 后最爽的是写同步代码并且不影响性能，不用担心 java spring 之类的线程池耗尽或者要去用 netty 搞回调，还有 go func() chan 、不用遍地搞 class 的各种方便，很少有人说 Go 爽是因为语法糖真丰富，很少有人沉迷于 Go 里茴字有哪 N 种写法，工程上的好处是实实在在的，但很多人的水平没到理解系统和工程的层次、他们是看不到的，很多人更在乎自己写代码奇淫巧技咬文嚼字的那点东西，所以会喷大道至简各种 > 能客观论证的是哪些方便做，哪些可以做，哪些做不了。 客观的 gopher 就是这样做的，包括我自己，自己项目适合哪些不适合哪些，其他选型哪些比 go 更适合，都是客观说，我没见过极端狂热的 gopher 去吹嘘 xx 功能只能用 go 性能要求特别高的场景，Go 就是达不到第一梯队，所以除了少量人在那用 Go 造缓存甚至数据库的轮子并且定位为取代传统性能语言，其他清醒的人很少去鼓吹这种，我是直接反对这种的 另外，很多人评价编程语言都有点脱离实际了，脱离工程实践：用设计和实现编程语言本身的标准去评价一个编程语言，脱离了绝大多数人使用编程语言是用于工程实践的实际情况。 比如：那些编程语言设计的相关理论，比如高级语法糖要比性能 N 倍的提升更好。 当然，如果项目本身对简洁没有要求，对性能没有要求，对工程管理没有要求，对很多都没有要求，随便找个什么模板或者老代码改改就能跑，都很高效率，如果都是按照这种出发点，我说的 Go 的优点也好缺点也好就都没意义了。 |
 |
86
stabc 13 天前
我认为 Go 最大的确定就是强加给使用者一些怪癖，比如 switch..case 之间没有缩进
|
 |
88
uni 13 天前
oop 应该要被扔进历史的垃圾堆了
|
 |
89
zhjunjun 13 天前
c#之父都不用 c#，各位破防不~
|
|
90
Nugine0 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 。 你也不用告诉我解法，这些坑我都知道。只是想说，在体验过这些后实在是不能称其为“优秀”。 |
 |
91
Manweill 12 天前
都认真去看看原文吧，选 go ，不是因为他多优秀，而是他在迁移这个工作上最合适，能符合 tsc 编译器这个工具的需求。带 gc 、函数式编程、内存共享的并发、以及足够低级的语言。不要总是自 high ，选合适的语言做合适的事情才是最合理。
|
|
92
Manweill 12 天前 1
|
 |
93
godspeedyou 12 天前
不是太懂楼上很多人一直在强调“不是因为 go 优秀”，如果 Anders Hejlsberg 选择了 go ，是不是说明在这个场景下 go 足够优秀呢
|
|
94
lesismal 12 天前
@Nugine0
我多解释下吧，我前面说那些“不是 Go 多优秀”的，不是指你 #54 是在说 Go 不优秀 at 你是因为 #63 说资历的问题，但本质上不是因为你说的资历问题、因为你没有明确指向谁 但是因为 #44 认为我是因为喜欢 Go ，我为了解释不是因为喜欢 Go 而怎样所以说了#41 结尾 而我也并不是在用资历说事情、因为工作十年二十年仍然是 curd 搬砖的人多了去了、资历并不代表水平，我说自己的经验和多个语言的体验对比里得出的结论罢了 因为没看到其他楼层有类似与资历有关的问题、似乎只有我提到的这个是与资历有关的所以觉得 #63 似乎是和 #44 一样在指向我 所以答复那些“不是 Go 多优秀”的时候顺便 at 里你，然后你就同样来辩论优秀不优秀的问题了 > 我并不认为要求别人给出“优秀”的评价是一种客观的做法。 我没有要求任何人给出优秀评价，而是反驳这些人，为什么如此了还不能称为优秀。 > 本来给出正面评价、想避免引战的人，现在会附带一些个人看法。 如果因为我的观点就导致了你带个人看法，那我表示抱歉 但我建议不要这样、这相当于丢掉了自己的理性判断，没必要 即使 ruster 再狂热，我也不会去放弃支持 rust > 你也不用告诉我解法，这些坑我都知道。只是想说，在体验过这些后实在是不能称其为“优秀”。 你列的这些点里，几乎没有对我造成过困扰、或者即使造成困扰也是微不足道的，相比于整个工程和性能效率，实在是没什么值得纠结的。 我不知道为什么人们总是喜欢用蹩脚的姿势或者稍微麻烦一点点都觉得是大问题，或者对年轻语言连点耐心都没有。 还有前面提到的“再加上社区提案爱答不理，谷歌需求立马安排，这种行为实在是难绷”，我是大力支持官方的，随便个什么提案往里乱加只会让 Go 变得更差，缓慢迭代这些是好事情。Go 官方和 Linus 的霸道风格我都大力支持！ |
|
95
lesismal 12 天前
@Nugine0
> > 我并不认为要求别人给出“优秀”的评价是一种客观的做法。 > 我没有要求任何人给出优秀评价，而是反驳这些人，为什么如此了还不能称为优秀。 都这样了还不算优秀，那么多人对不优秀的评价就客观吗？ 别人认为这种不客观、所以反驳就是不客观吗？ |
|
96
lesismal 12 天前
@Manweill #91 是的，所以选型了一个性能给力、自带 gc 省力开发效率高、并发极大便利、底层能力、函数方式编程个方面都适合，但只要不是嘴上承认这些点都算优秀，就不是 Go 多优秀，因为别的多种语言也都分别有这些对吧？
即使别人选型 Go 了并且说明了为什么 Go 在多个方面都很适合、适合也不是因为优秀，只是因为适合，即使脱离了这个 case 本身也不用考虑 Go 本身、Go 本身就不是多优秀对吧？佩服你们的推理能力。 最适合的候选人，即使不说他多优秀也就算了，一个个的都站出来说不是因为他多优秀、不带任何至少它满足了个方面需要的前置条件，这不就是在那不屑地假装理中客地暗黑吗？ 不要只觉得喜欢 Go 的人是在自 high ，无脑黑 Go 和不屑承认 Go 优点优秀的人难道不是自 high 吗？ 无脑否定 Go 的人不只是自 high ，而且还很不喜欢务实的事物，不知道有什么可出来炫耀的 |
 |
97
liuliuliuliu 12 天前
不是，为什么这么多人还在说 .net 要带运行时啊？
aot 出来几年了，现在.net 可以原生编译，不需要带运行时了 |
|
98
lesismal 12 天前
@godspeedyou
#93 国人爱谦虚，很多事情都会谦虚，比如自己拿了什么冠军还是要说“我还有很多可以提高的地方”。但这个案例里，他们都不是谦虚了，就是不愿意承认 Go 的好。 说好听点是他们懂得多，说不好听点就是很多人喜欢踩一脚来变相抬高自己。 |
 |
99
mooyo 12 天前
@liuliuliuliu .NET 的 AOT 到现在都还是一坨。。一堆官方库都还没完全 AOT 化
|
|
100
Nugine0 12 天前
@lesismal #94
> at 你是因为 #63 说资历的问题 那我明确一下，#63 是指向 #60 。无意冒犯你。 > 如果因为我的观点就导致了你带个人看法，那我表示抱歉 > 但我建议不要这样、这相当于丢掉了自己的理性判断，没必要 在别的评论区我还是会保持避免引战，给出什么语言适合什么场景的评价，而不会一概而论哪个语言就是优秀。 即便有人说 rust 有什么问题，只要客观存在，我也会同意。 Go 1.0 已经 13 年了，不能论质量就是成熟，论问题就是年轻。 > 严格来讲不是否定，但在宽泛的社交语境，这约等于否定、并且实际效果就是偏否定的 > 我没有要求任何人给出优秀评价，而是反驳这些人，为什么如此了还不能称为优秀。 没说优秀=否定优秀=需要反驳，我觉得你不需要坚持这个链条去反驳任何人。 讲一讲 Go 的相对优势适用于哪些场景，分享你自己的实际经验，已经足够了。 |
Select Language