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

[drymonfidelia]

C# 性能远超 Go 来源

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

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

另外 C#和 TS 大部分类型都对应，实在找不到要用 Go 的理由

[iyiluo]

go 可移植性好

[drymonfidelia]

@iyiluo C#也能跨平台，虽然现在.NET Core 跨平台还是有些莫名其妙的问题，有的情况会内存泄漏，但已经可以上生产了

[cyp0633]

https://github.com/microsoft/typescript-go/discussions/411

[drymonfidelia]

@cyp0633 我看过这个讨论串了，只提了 a bit of a vote of no confidence in C# 没有提具体的原因

[guotie]

他说了，C#更面向对象，js/ts 跟 go 更接近，更好 1:1 移植

[stimw]

https://github.com/microsoft/typescript-go/discussions/411#discussioncomment-12464695

已经有很多讨论了，这是一个相对官方的回复

[stimw]

@drymonfidelia 具体原因楼层我已经发了

[cyp0633]

@drymonfidelia #4

&t=1154s

[k9982874]

如果用 c#便宜 ts ，以后装 react/vue with ts 是不是 npm 还得先装个.net runtime 。
这一下.net 的使用量就上来了，今年编程语言榜第一的就是 c# + .net 了（乐

[DTCPSS]

C# 设计上是字节码优先的，虽然有 AOT 但是缺少实战检验，而且最初也不是为这类场景设计的，有些环境会有问题。
Go 的代码组织方式和现有的代码更相近（函数 + 数据结构，非 OOP ），方便一比一翻译。

[drymonfidelia]

@k9982874 我挺希望这样，现在 C#的跨平台 UI 框架没一个完善的，如果微软能让 C#上 Rank #1 我觉得这个问题能被改善

[Hellert]

人家明确说了是移植，不是重写。单就这一点来说，C#是面向对象的，就不合适。

[drymonfidelia]

@Hellert 如果单纯是这个原因的话，面向对象的语言也可以不使用和对象相关的特性

[k9982874]

@drymonfidelia 别闹，现在 node_modules 已经够地狱了，.net 再拖家带口住进来，nodejs 就不能要了

[Mexion]

@k9982874 现在 C#也可以 AOT ，所以这个不是问题

[sagaxu]

他们是 port ，不是 rewrite 。用 Go 可以很简单的按文件翻译，代码长差不多。


如果用 C#，为了高性能，就要大量使用 Span<T>和 Memory<T> ，那 port 工作量就太大了。C#的优势，模式匹配和异常处理，不擦除的泛型等等，都完全用不到，aot 编译耗时比 Go 长很多倍，得不偿失。

[TanKuku]

因为 LOGO 都是蓝色的

[idealhs]

我才知道有的语言编译器是不自举的

[lesismal]

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

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

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

[iamzcr]

@lesismal 无比赞同啊，有些人一直拿"大道至简"这个来黑

[Bazingal]

@k9982874 #9 没听过 aot ？

[InkStone]

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

基于这个案例，你其实可以把“Go 是否是一门设计优秀的语言”这个问题近似转换成：“Javascript 是一门设计很优秀的语言吗？”

我想后者比前者的争议小多了。

[redbule]

@lesismal C#最大的问题就是当年抄了 JAVA 的 oop ，整了一套复杂累赘的继承系统。后面发现路子歪了，疯狂打补丁，语法糖一个接一个，但已经逃不出 oop 的框子了。注定和简单无缘。

[InkStone]

@redbule OOP 其实没啥问题，有问题的是 Java 这种对 OOP 支持不好，又非要求开发者用 OOP 的规范去写的语言。

[alleluya]

@redbule 我记得以前在 v2 上看过有人说 ts 是 lite C#... 这个 lite 是从哪来的?

[redbule]

@InkStone 按你这个逻辑。js 有多种范式的写法。那么问题来了，为什么 tsc 的写法要像 go 呢？它也可以像 C#和 java 一样用 oop 写。是不是可以说 oop 就是不行呢。

[Mexion]

@redbule 因为直接代码转换过来简单，TS 编译器很少用到类的写法，函数式写法比较多，用 Go 可以直接改一下关键字和少量语法就转过来，如果用 OOP 写法差异太大改动就太大了。简而言之，TS 的开发团队不想花太多时间和精力在代码转换这件事上。

[InkStone]

@redbule 恕我直言，我看了三遍你的回复，感觉你想表达的意思是：tsc 用了什么写法，那其它的写法一定都不行？

这话你自己觉得说得通么？

[ambition117]

负责这个项目的是 c#之父，c#之父也不用 c#，破防不？

[qxmqh]

go 简单啊，不用面向对象，基本没有类这个概念，结构体 +interface 能完成 90%以上的任务，编译又快，内存占用又小，天生支持高并发，这些是个人都知道的，有啥可奇怪的。

[csys]

最直接的原因就是 go 足够“原始”

C#是高度抽象的语言，可移植性很差的，java 同理

这是个很简单的哲学命题

[lesismal]

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

@InkStone #22

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

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

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

[InkStone]

@lesismal 事实上，我回帖的时候看错了帖子，我说的“主楼”就是你贴的这个链接。

所以我想应该是我需要建议你仔细看看隔壁帖子。它说的就是我总结的这个意思。

[lesismal]

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

[zhangqwesc0]

这个 benchmark 里面，排除掉*开头的"safe"实现里面，go 不是仅次于 c/c++和 rust 吗

[lesismal]

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

[lesismal]

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

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

[InkStone]

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

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

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

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

[nziu]

@sagaxu 这图其实就说明了一切 tsc 的源码就是把 ts 当做一门带 gc 的 c 来写，为啥选 go 不言自明但是拿来论证 go 如何优秀确实难绷。

[rarpainting]

有没有人上 github 提个 issue 问下

[lesismal]

@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 各种，好和不好都是亲身体验和总结，不是站队性质也不是跟风性质的观点输出

[InkStone]

@lesismal
> 支持和好用是两码事
这就是为什么我说 Go 支持底层操作之类的只是特点而不是优点。

Go 的底层操作并算不上很好用，性能也有很大优化空间。我知道它是权衡利弊之后做成这样子，但在编译器这个领域，它在权衡中舍弃的那些东西还是挺重要的。

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

[lesismal]

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

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

[InkStone]

@lesismal
你看你又在这里扯这些没边的了，讨论就实打实讨论具体的问题，不用说这些没用的。

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

[lesismal]

@InkStone #42

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

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

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

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

[lesismal]

@InkStone #44

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

[lesismal]

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

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

[InkStone]

@lesismal

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

> 但是哪个其他语言的缺点少而且优点又像 Go 这么大呢？
Go 的优点在各种语言中并不算特别突出，缺点比 Go 少的语言更是数不胜数。

如果你非要我提一门这样的语言出来，那底层语言我提名 C ，几乎完美无缺的语言，它在整个编程体系重要到它的缺点都不再是缺点。

[thinkershare]

要吵架可用去这里
https://github.com/microsoft/typescript-go/discussions/411#discussioncomment-12467996
微软给出来的理由在我看来是站不住脚的，除了他们想要偷懒，不想完全重写。

[lesismal]

@InkStone

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

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

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

[mahaoqu]

Go 和 TS 一样都使用名义类型应该算是最大的类似之处了，其他所有主流语言都不支持这一特性。

[lesismal]

@InkStone #48

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

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

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

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

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

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

[crackidz]

Anders Hejlsberg 的技术决策真的适合所有人看一下，其实很说明技术选项的考量，尤其是现有仓库的迁移

当然，很多显示情况下，自己遇到项目时，更多会是政治性的或者党争了...而且作为 Pascal 专家 / C# 首席架构师和设计者之一，肯定是充分考虑了多重因素，比如他也提到尝试过 C# 的工作（并且已经可以运行了），但是最终发现并不合适

[Nugine0]

人家想找个能支持 typescript 旧代码库风格的原生语言，把逻辑原原本本地**移植**过去，选 Go 很正常。
如果要彻底**重写**所有架构，人家说了，用其他语言也合适。而且未必达不到 Go 的性能。

根据任务目标进行决策没什么毛病，想参考的话，看看你的任务目标是否一样。

[crackidz]

另外，Anders Hejlsberg 的回复里也反映了微软自身在开源社区的转身，这可以作为微软封闭生态到逐步开放的一个缩影。当然，过去几年微软其实一直在做出改变。往前十年，你甚至无法想象现在的微软

[kiwi95]

@thinkershare #49 这样的工程完全重写 90%的概率完成不了，就算完成了，还有可能 90%功能不全或者 break 原来的逻辑，并且完成之后新旧两版都要维护的，不可能旧版本就扔了不要了吧，一个 patch 怎么在两个版本都能应用也是非常困难的，这不是偷懒，而是务实。

[sunshower]

要是用 C#，大家岂不是又要骂微软封闭了
哪个有好处用哪个，不是挺好的

[leokun]

[thinkershare]

@kiwi95 无所谓，反正微软这个态度，我是会放弃.NET 。任何基础设施工具我都不会再用 C#写了。我本来还在用 C#写一个 bacnet 的协议库，现在也打算放弃了。

[dbskcnc]

以 Anders Hejlsberg 的资历，在座的大概给人家提鞋的资格都没有，就不要指点江山，大放厥词了。

[willchen]

开源角度来讲 go 的社区比 c# 应该还是好点的

[sagaxu]

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

Rust 很优秀，但为什么进 Linux 内核阻力重重？是 Linus 等大佬学不会吗？大概率还是工程问题，而非技术本身的问题。

[Nugine0]

资历只能影响一个人说话的份量，但不会自动堵上别人的嘴，望周知

[redbule]

@InkStone #28 那 js 写的和 go 像，就能用 js 评价 go 。逻辑通吗？

[weiwenhao]

typescript 编译器的主要功能就是编译为 javascript 吧。相当于是文本转换的功能，用 python 写都无可厚非，也就是编译速度快慢。

不太了解 c# 的跨平台交叉怎么样，是否方便，选择 golang 一般是看重了 golang 的 auto gc(对于编译器这种一次性应用，内存没啥用), 超级方便且独立跨平台编译特性(不需要 llvm)，语法也足够简单, 现在 golang 的现在的运行速度也足够优秀，即使是 cpu 密集应用，性能上不会比 rust 逊色多少。

当然我觉得如果 rust 重构应该会带来更加极致的 ts 编译为 js 的编译器速度。

[DrakeXiang]

原贴说得挺明白了，https://github.com/microsoft/typescript-go/discussions/410 这个贴也说明了为什么是移植不是重写，简单来说就是 go 和现有的代码最像，能 1:1 移植，能减少产生出的新问题，甚至要保留现有代码的 quirks 以实现最大的兼容性，同时还能在后续同时维护的时候两边都能快速修改