看到今天群里有人讨论微软用 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 <amp-youtube data-videoid="10qowKUW82U" layout="responsive" width="480" height="270"></amp-youtube>&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 无比赞同啊，有些人一直拿"大道至简"这个来黑