esbuild为什么不用Rust，而使用了Go?

其实写 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