Bun 发布了 beta 版本: Bun is a fast all-in-one Javascript runtime

zig 还是第一次听说

@binhb zig 可以做 C 后端，平替 gcc/clang

@binhb #1 zig 用在 rust 跨平台编译有奇效

用 Javascript 而不是 v8 看来是 ES conformance 上正确的选择。
@janxin 想多了，clang 是前端，后端是 LLVM 。
且不说 zig cc is not the main purpose of the Zig project ，zig cc 也就是套皮 zig clang 而已，后者依赖 libclang 。所以 zig 做的连前端都算不上，只是个 driver 。
装 zig 去编译 C 也就是只需要 C 前端的时候省事（然而作者起码没放弃 C++）。但真要轻便，除非要一次性搞定所有 target arch ，直接 tcc 不更实用么。

@FrankHB 看了下，好像是我 out 了，现在都有 zig c++了。
不过除了包装东西给 zig 调还是意义不大。

作者单人输出能力很强，测试效果很好，值得关注。
不过 bun 还处于早期，issue 里一大堆段错误，也有内存泄露和崩溃问题，有点担心它的性能是不是通过牺牲安全性和正确性换来的。

@FrankHB
应该是 JavascriptCore 吧，好像是苹果公司的引擎吧。
不知道它跟 V8 相比有什么优势。

js 工具链是真的卷。卷 rust ，卷 go ，现在又来卷 zig 。rust 、go 起码有稳定版本，zig 现在还是很早期阶段。

ts/jsx 转换、bundler 使用 zig 实现，也加入 node_modules 的支持算法，这部分可以对标 esbuild （ go 写的）。bun 也加入 napi 支持，似乎可以直接使用 nodejs 的一些 c 拓展。

JavascriptCore 用来跑 js 代码。JavascriptCore 性能可能比 v8 差点，至少很多 benchmark 结果是这样的。README 上写是比较容易集成到 zig 代码吧。

编译似乎是用 build.zig ，说不定自己编译 bun 会比较简单。

roadmap 还很长很长。不知道啥时候能清掉。

@FrankHB zig 在做自己的 backend 了，不过目标时间是 1.0 https://kristoff.it/blog/zig-new-relationship-llvm/

zig cc 确实不是主要目标，但是很多公司在用 zig cc 。uber 为此还专门赞助了 zig ，专门签了独家协议优先解决 zig cc 的问题

这性能确实牛批啊，JS 的工具链真的太卷了

看这[星星的涨势]( https://star-history.com/#Jarred-Sumner/bun&Date), 7 天时间从 2k 涨到 12k ！ web 前端这块也太热了吧

@DOLLOR 是 JSC ，没注意打快了输入法选词一回车给跳了……
JSC 唯一较早就支持 ES6 的主流实现。到了 2022 ，它居然仍是目前唯一具有 ES6 PTC 的少数实用 ES 客户端实现（剩下也就 XS6 和 Duktape 俩没法相提并论的弟弟）。
关键点是，和其它特性不同，这里其它实现缺少的 PTC 对实现结构的影响是重量级的，原则上无法通过 babel 之类的外加运行时 polyfill 套皮高效正确实现（实际上不说多出来的开销，现在就没一个正确的），要添加正确的实现基本就只有回炉拆了重造。因此第三方现实不可能补救这个特性缺失带来的缺陷。
尤其可耻是 v8 曾经有--harmony-tailcalls ，后来因为可笑的“工程”理由给干掉了。（那你费劲实现干嘛？）

@FrankHB JSC 唯一→JSC
低级 typo……