Hacker News 讨论: https://news.ycombinator.com/item?id=31993429
1
binhb 2022-07-06 16:22:31 +08:00 via iPhone
zig 还是第一次听说
|
3
SingeeKing 2022-07-06 17:17:26 +08:00 2
@binhb #1 zig 用在 rust 跨平台编译有奇效
|
4
FrankHB 2022-07-06 18:23:40 +08:00
用 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 不更实用么。 |
6
Nugine0 2022-07-06 19:48:30 +08:00 via Android
作者单人输出能力很强,测试效果很好,值得关注。
不过 bun 还处于早期,issue 里一大堆段错误,也有内存泄露和崩溃问题,有点担心它的性能是不是通过牺牲安全性和正确性换来的。 |
8
yuekcc 2022-07-06 23:00:01 +08:00 1
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 还很长很长。不知道啥时候能清掉。 |
9
janxin 2022-07-07 09:38:15 +08:00 via iPhone
@FrankHB zig 在做自己的 backend 了,不过目标时间是 1.0 https://kristoff.it/blog/zig-new-relationship-llvm/
zig cc 确实不是主要目标,但是很多公司在用 zig cc 。uber 为此还专门赞助了 zig ,专门签了独家协议优先解决 zig cc 的问题 |
10
RockShake 2022-07-07 11:21:18 +08:00
这性能确实牛批啊,JS 的工具链真的太卷了
|
11
haoliang 2022-07-07 21:36:39 +08:00 1
看这[星星的涨势]( https://star-history.com/#Jarred-Sumner/bun&Date), 7 天时间从 2k 涨到 12k ! web 前端这块也太热了吧
|
12
FrankHB 2022-07-13 22:25:08 +08:00
@DOLLOR 是 JSC ,没注意打快了输入法选词一回车给跳了……
JSC 唯一较早就支持 ES6 的主流实现。到了 2022 ,它居然仍是目前唯一具有 ES6 PTC 的少数实用 ES 客户端实现(剩下也就 XS6 和 Duktape 俩没法相提并论的弟弟)。 关键点是,和其它特性不同,这里其它实现缺少的 PTC 对实现结构的影响是重量级的,原则上无法通过 babel 之类的外加运行时 polyfill 套皮高效正确实现(实际上不说多出来的开销,现在就没一个正确的),要添加正确的实现基本就只有回炉拆了重造。因此第三方现实不可能补救这个特性缺失带来的缺陷。 尤其可耻是 v8 曾经有--harmony-tailcalls ,后来因为可笑的“工程”理由给干掉了。(那你费劲实现干嘛?) |