Hacker News new | ask | show | jobs
by generichuman 1022 days ago
It could force changes to Bun _internals_, which doesn't really affect users if the Bun team does not want to break API.
2 comments

Changes to Zig can still be very significant. I found myself stuck between a rock and an hard place when I found out that:

- Zig v0.11 doesn't have async/await, which I needed, because they haven't implemented it yet on the self-hosted compiler;

- I couldn't use v0.10 due to some bugs with comptime in the old compiler, which are solved in v0.11.

Still, while bold, I don't think it's totally unwarranted to tag Bun 1.0. They may have to put some extra effort here and there to work around the language's instability.

This is not a critique of the Zig team, they make it very clear that the language is not ready for production use yet.

I’m just not sure how you guarantee no changes to the API without knowing the size or scope of changes that may come to the language it’s built on.
As an example, Java does just fine at guaranteeing its own semantics completely independently of what happens to C++.
True, though you can't claim that's an analogous situation - C++ wasn't in alpha when the JVM was implemented.

Decoupling is of course possible, but the difference here is that the lang powering the runtime is not guaranteed to remain the same language it currently is, since it's in active initial development. That introduces a unique axis of risk to runtime stability, it's dishonest to pretend otherwise.

Well sure if you start adding more conditionals and change the original question you can call anyone who answered the original question in good faith a liar.
That's not what happened here. If you have difficulty keeping context of the thread we're all in, scroll up and reread. Snarking (and being wrong to boot) contributes nothing to the discussion.