upvote
> You could write a JS engine with Zig-like idioms (arena allocation, static initialization)

Arena allocators & static initializers are not novel. You'll find them in high performance C++ projects as well, such as LLVM or JavaScriptCore. But arena allocators have the quite significant limitation that they only help when everything being allocated in them have approximately the same lifetime. So they don't help when you need to allocate memory to provide the native implementation of a JavaScript object, for example (eg, FFI).

reply
> You could write a JS engine with Zig-like idioms (arena allocation, static initialization)

Could you actually? That seems like a bad fit for a JS engine to me. Predictable memory requirements are great when you can have them, perhaps you can avoid complexity then, but for a JS engine?

reply
Why not using Swift?
reply
Swift is very weak outside Apple ecosystem, compared to Rust. Not sure nowadays, but Swift used to have breaking changes each major release, that's a non go for a big project.
reply
But Swift has a stable ABI which neither Zig nor Rust could provide.
reply
How important is stable ABI for projects like Bun? I think it only matters if you are building a shared library.
reply
only on macOS. On other platforms ABI is not stable.
reply
Andreas Kling talked about it. It boils down to C++ interop sucks (no surprise for lang made by Apple), ecosystem is tiny, Rust works well enough with LLMs.

https://youtu.be/DbHjKi_jASY

reply
Swift is one of the few toolchains that actually has some kind of builtin C++ interop, alongside Objective-C++, D, .NET (via C++/CLI), Carbon (eventually).
reply
He just wanted to use LLMs for coding, and not enough training data on Swift code exists for his use case. Admitting to that would be rather silly, so here we have this sentiment now exist rent free in people's brains.

The C++ interop of Swift is perfectly fine, to such a degree that FoundationDB is now using it effectively alongside its C++ origins.

reply