其实写 bundler 这种事情,GC 未必是劣势。写一个打包工具,大部分的工作是字符串拼接和图遍历。对于图数据结构,GC 是一个很好的辅助工具。用 Rust/C++ 你得考虑非常多内存分配的细节。
用 Rust/C++ 写过图的对此应该都有很深的体会。对于 Rust 这种尽量避免循环引用的语言,怎么表示图结构我猜现在还没有一个很好的方案吧。而一个成熟的 GC 帮你解决了这些问题。
Rust/C++ 这种无 GC 语言的在内存上优势则是在于分配和释放的稳定,但是性能(吞吐)上未必有优势。比如大量的内存分配的释放在 Rust/C++ 里面都是很慢的(当你 parsing 的时候)。因此你需要做很多优化,比如说内存池,而这些都是侵入式的,会让你的代码变得 ugly
Go 还有一个优势是原生的轻量级线程的支持。这些 Rust/C++ 当然能实现,但是 Go 还实现了一个非常优秀的调度器,调度 IO 和计算。而给 Rust/C++ 的只有 native thread,如果你又想做一套调度,那又是何苦呢。
1、拿 rust 写代码确实心智负担很高,很多时候很难有内存去做高层的设计,此外 rust 的智能指针和 pattern match 的适配度很低,所以很多代码要缩进一层又一层
2、此外 rust 对复杂所有权的数据结构很不友好,而这对很多静态分析来说都是必要的。rustc 表示我选择躺平用 arena
3、esbuild 的代码为了效率,整个流程只过两遍 ast,代价就是代码写成一大坨,显然还是 babel/swc 这种传统编译器的分 pass 模式更方便扩展,他们提供的功能也更丰富
4、即便如此 esbuild 作为转译器的效率也没超过 swc,可以说是责任全在 go 的垃圾编译器/运行时上了
5、此外不支持 ADT 的语言(是的,包括 CPP)都不适合表达 AST,强行拿来写编译器属于是削足适履了,然而谁叫 ml 系没流行起来呢TG:li9047