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

[drymonfidelia]

C# 性能远超 Go 来源

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

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

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

[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 问下