看到今天群里有人讨论微软用 Go 重写 TypeScript 编译器,为什么不是用他们自家的 C#? C#在大部分 benchmark 项中性能都远超 Go, TypeScript 编译也不是在浏览器进行,不用考虑编译器体积
C# 性能远超 Go 来源
benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fannkuchredux.html
以及这个网站的大部分项目
别的 benchmark 网站结果也大致相同
另外 C#和 TS 大部分类型都对应,实在找不到要用 Go 的理由
go 可移植性好
C#也能跨平台,虽然现在.NET Core 跨平台还是有些莫名其妙的问题,有的情况会内存泄漏,但已经可以上生产了
github.com/microsoft/typescript-go/discussions/411
我看过这个讨论串了,只提了 a bit of a vote of no confidence in C# 没有提具体的原因
他说了,C#更面向对象,js/ts 跟 go 更接近,更好 1:1 移植
github.com/microsoft/typescript-go/discussions/411#discussioncomment-12464695
已经有很多讨论了,这是一个相对官方的回复
具体原因楼层我已经发了
#4 &t=1154s
如果用 c#便宜 ts ,以后装 react/vue with ts 是不是 npm 还得先装个.net runtime 。
这一下.net 的使用量就上来了,今年编程语言榜第一的就是 c# + .net 了(乐
C# 设计上是字节码优先的,虽然有 AOT 但是缺少实战检验,而且最初也不是为这类场景设计的,有些环境会有问题。
Go 的代码组织方式和现有的代码更相近(函数 + 数据结构,非 OOP ),方便一比一翻译。
我挺希望这样,现在 C#的跨平台 UI 框架没一个完善的,如果微软能让 C#上 Rank #1 我觉得这个问题能被改善
人家明确说了是移植,不是重写。单就这一点来说,C#是面向对象的,就不合适。
如果单纯是这个原因的话,面向对象的语言也可以不使用和对象相关的特性
别闹,现在 node_modules 已经够地狱了,.net 再拖家带口住进来,nodejs 就不能要了
现在 C#也可以 AOT ,所以这个不是问题
他们是 port ,不是 rewrite 。用 Go 可以很简单的按文件翻译,代码长差不多。
如果用 C#,为了高性能,就要大量使用 Span
因为 LOGO 都是蓝色的
我才知道有的语言编译器是不自举的
看到过好多次说 C#比 Go 好的了,希望这个事情让你门清醒。。。
BTW ,这事情里的函数式不是通常说的函数式编程
函数式太多花活、隐藏机制、性能浪费,不是什么好玩意
OO 太多累赘、啥都得 class 、顶层设计难以预计未来、难以高效应对快速变化,不如面向过程更加通用
Go 很务实,有的人认为他平庸,简洁、甚至 N 倍性能提升都进不了这些认为 Go 平庸的人的“法眼”,反过来还要喷“大道至简”,我无法对这些人的智力水平作出评价,因为我不想贬低别人但也更不想撒谎。
无比赞同啊,有些人一直拿"大道至简"这个来黑
#9 没听过 aot ?
我想主楼已经说得很清楚了,选用 Go 不是因为 Go 多好,而是因为 Go 最像 Javascript 。
基于这个案例,你其实可以把“Go 是否是一门设计优秀的语言”这个问题近似转换成:“Javascript 是一门设计很优秀的语言吗?”
我想后者比前者的争议小多了。
C#最大的问题就是当年抄了 JAVA 的 oop ,整了一套复杂累赘的继承系统。后面发现路子歪了,疯狂打补丁,语法糖一个接一个,但已经逃不出 oop 的框子了。注定和简单无缘。
OOP 其实没啥问题,有问题的是 Java 这种对 OOP 支持不好,又非要求开发者用 OOP 的规范去写的语言。
我记得以前在 v2 上看过有人说 ts 是 lite C#... 这个 lite 是从哪来的?
按你这个逻辑。js 有多种范式的写法。那么问题来了,为什么 tsc 的写法要像 go 呢?它也可以像 C#和 java 一样用 oop 写。是不是可以说 oop 就是不行呢。
因为直接代码转换过来简单,TS 编译器很少用到类的写法,函数式写法比较多,用 Go 可以直接改一下关键字和少量语法就转过来,如果用 OOP 写法差异太大改动就太大了。简而言之,TS 的开发团队不想花太多时间和精力在代码转换这件事上。
恕我直言,我看了三遍你的回复,感觉你想表达的意思是:tsc 用了什么写法,那其它的写法一定都不行?
这话你自己觉得说得通么?
负责这个项目的是 c#之父,c#之父也不用 c#,破防不?
go 简单啊,不用面向对象,基本没有类这个概念,结构体 +interface 能完成 90%以上的任务,编译又快,内存占用又小,天生支持高并发,这些是个人都知道的,有啥可奇怪的。
最直接的原因就是 go 足够“原始”
C#是高度抽象的语言,可移植性很差的,java 同理
这是个很简单的哲学命题
我想主楼已经说得很清楚了,选用 Go 不是因为 Go 多好,而是因为 Go 最像 Javascript
#22
得出这样的结论,我大概也懂了为啥你们认为 Go 平庸——Go 的优点一点都看不到或者不承认
只能建议看下隔壁帖子了:
/t/1117764
你们认为 Go 平庸就认为吧,#19 里我已经说过了
事实上,我回帖的时候看错了帖子,我说的“主楼”就是你贴的这个链接。
所以我想应该是我需要建议你仔细看看隔壁帖子。它说的就是我总结的这个意思。
是的,所有天生 OOP 以 Class 为主要模式的,都有这个毛病,十多年前没有这么高速发展的 IT 互联网的时代,还好,时代变了之后,业务种类和规模越来越大了,需求迭代越来越快了,OOP 尾大不掉、顶层设计难度和开发效率拉垮。所以很多独角兽在没有历史包袱的领域大量用 Go 从头造甚至抛弃旧的技术栈用 Go 大量重构,国内一些明星企业做了太多这种示范了,但就是有很多人看不懂、无脑喷 Go
这个 benchmark 里面,排除掉*开头的"safe"实现里面,go 不是仅次于 c/c++和 rust 吗
#33 我说的都是内容的实质、不乱哪个帖子、Go 的优点都在那,所以其实是哪个帖子根本不重要
#33
你可以看下隔壁#12 的总结,前面几条可都不是因为 Go 跟 JS 像,用 Go 重写 TS 编译器也不是因为 Go 像、重写 TS 编译器本身的目的是在于提升 TS 编译器的性能和体验。
要说像那还是 TS 自己跟自己最"像"、本来就是自举何必要换语言重写呢?
所以,得出 Go 和 JS 像是原因这种结论,可能是因为自己对 Go 的刻板印象、首先默认 Go 不行、然后拿着结论去找原因,本末倒置了、推导的方法不对、第一步就错了
事实上,里面提到的 Go 的优点就是一条:并发编程支持好。
其它的都只能说是“特点”。比如本身支持底层操作(底层语言不支持底层操作这像话吗?),有 GC ,编程范式和 tsc 原有的实现方式接近等等。
当然,真说起来,说 JS 和 Go 像确实也没那么贴近事实,更贴近事实的是:Go 和 tsc 里使用的那一部分 ts 语法子集(接近于带 typehint 、不怎么玩 prototype 等花活的 js )很像。
你喜欢 Go 的心情我能理解,但自始至终你都没说出什么 Go 什么优点来,这实在有点难绷……
这图其实就说明了一切 tsc 的源码就是把 ts 当做一门带 gc 的 c 来写,为啥选 go 不言自明但是拿来论证 go 如何优秀确实难绷。
有没有人上 github 提个 issue 问下
#38
事实上,里面提到的 Go 的优点就是一条:并发编程支持好。
所以现在你的观点里增加了一条 Go 的优点,我多少欣慰了一点。。。
其它的都只能说是“特点”。比如本身支持底层操作(底层语言不支持底层操作这像话吗?),有 GC ,编程范式和 tsc 原有的实现方式接近等等。
支持和好用是两码事,其他很多语言也都有“协程”之类的,但是好不好用?我个人从早期的 lua 、erlang ,到现在的一些语言的 async await 或者 virtual thread 大概都了解过一些,只能说 erlang 的进程和 goroutine 是一样好用的、但 erlang 本身比较拉,其他的,让我实际工作中去用我是不会去这样糟蹋自己去用的
当然,真说起来,说 JS 和 Go 像确实也没那么贴近事实,更贴近事实的是:Go 和 tsc 里使用的那一部分 ts 语法子集(接近于带 typehint 、不怎么玩 prototype 等花活的 js )很像。
“真说起来”,那肯定是不像,但人家只要有采访中提到的这部分相像就已经足够作为多个语言中选型的重要理由之一了。
实际上这个选型主要是两个维度:
- 是否能实现性能优化和体验的提升:为了达到这个目的 c/c++/rust/go/c#等语言都可以
- 在满足 1 的前提下,重写编译器的工程效率,因为考虑到已有的 ts/js 的可重用性,go 与 js“相像”这个优势就凸显出来了
你喜欢 Go 的心情我能理解,但自始至终你都没说出什么 Go 什么优点来,这实在有点难绷……
我从没有因为自己喜欢 Go 而去盲目吹嘘 Go 的好或者贬低其他语言的不好:
- 我说 Go 的好的时候完全就是因为我认为这些点真的好、并且是我亲身体验的好
- 我说其他语言的不好的时候完全就是因为我认为这些点真的不好、并且是我亲身体验的不好
我自己干这样差不多二十年了,学习、体验过十多种语言,实际项目中用到过的至少写了几千几万行的代码的包括 c/c++/lua/py/c#/js nodejs/as/go 各种,好和不好都是亲身体验和总结,不是站队性质也不是跟风性质的观点输出
支持和好用是两码事
这就是为什么我说 Go 支持底层操作之类的只是特点而不是优点。
Go 的底层操作并算不上很好用,性能也有很大优化空间。我知道它是权衡利弊之后做成这样子,但在编译器这个领域,它在权衡中舍弃的那些东西还是挺重要的。
Go 的缺点大家都说过很多了我也懒得说了……现在不是别人没正视 Go 的优点,而是你没正视 Go 的缺点。
很多人因为自己学过什么,就会有什么的思维惯性,然后对其他的异类事物会有抵触,尤其是如果自己所学的东西看上去更加复杂、先进,比如花样多、语法糖多、语言理论现代化,看上去好像很高级,就会反对看上去更加低级的比如 Go 。
经济学上相当于沉没成本效应,心理学上大概叫首次效应,玄学上这叫迷了眼
真正成为语言邪教的是这种人,而不是抛开这些花哨、踏实从工程角度去考虑工程实践的实用主义的人,谷歌早期宣传的时候的定位,就是这种工程实践的实用主义哲学、以及很多人眼中所谓的和嘴上黑化了的"大道至简",只顾皇帝的新衣不看内里,是做不好实事求是的。
你看你又在这里扯这些没边的了,讨论就实打实讨论具体的问题,不用说这些没用的。
难道你以为就你一个人写过十几门语言么?对能独当一面的开发者来说,这都是最基本的好吧。
所以设计模式,实是是一种方法,一种为了解决某种或某类物定问题所使用的设计模型。据说,在编程语言方面有100多种设计模式,而在现实生活中,传说有上成千上万个模式,比如写书有写书的…
一个月 20$ 破公司肯定舍不得 这点钱其实真的不用纠结,代码整齐度有了,也规范了。给自己带来的产出>支出就好了 所以我没买。。。用用 tabs 功能得了~ 只要产…
我有在不同地方购买优惠的云服务器的癖好,一年优惠过期之后也不续费,阿里云、华为云以及海外的小鸡都有购买。 但是我不部署 mysql 在机器上,因为到期了迁移比较麻烦。 所以之前…