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

lesismal

181 天前

@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

181 天前

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

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

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

lesismal

181 天前

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

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

InkStone

181 天前

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

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

lesismal

181 天前

@InkStone #42

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

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

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

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

lesismal

181 天前

@InkStone #44

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

lesismal

181 天前

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

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

InkStone

181 天前

@lesismal

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

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

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

thinkershare

181 天前

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

lesismal

181 天前

@InkStone

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

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

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

mahaoqu

181 天前

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

lesismal

181 天前

@InkStone #48

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

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

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

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

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

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

crackidz

181 天前

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

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

Nugine0

181 天前

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

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

crackidz

181 天前

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

kiwi95

181 天前

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

sunshower

181 天前

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

leokun

181 天前

thinkershare

181 天前

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

dbskcnc

181 天前

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