4 ms·

One thing I really don't unserstand is how bun already reached stability with it's 1.0 release (https://bun.sh/blog/bun-v1.0 https://bun.sh/blog/bun-v1.0) while

by shemii 3y ago

One thing I really don't unserstand is how bun already reached stability with it's 1.0 release (https://bun.sh/blog/bun-v1.0 https://bun.sh/blog/bun-v1.0) while being written in Zig, which still hasn't reached it's 1.0 release.

fastball 3y ago
Bun is compiled to a binary, so not sure it matters how stable the underlying language is if Bun itself has a stable API?
- KolmogorovComp 3y ago
  That’s the point OP is making, even if the program is bug-free, given the compiler’s current state there’s a chance the compiled binary has bugs (due to miscompilation). Now that can happen with every compiler but using one in still in alpha significantly increases the risk.
  - fastball 3y ago
    Does it help at all that Zig is LLVM-based?
    - wredue 3y ago
      Not particularly. And zig is moving away from llvm anyway.
kreetx 3y ago
Versioning isn’t an exact science, and people use whatever they see fit, both for technical but also marketing purposes.
brabel 3y ago
If you test your software built on Zig close to 100% then you can be pretty confident you didn't run into any of the Zig compiler bugs. Bun has certainly run into them but they can almost always be worked around... if you work around all problems and manage to catch everything then yeah, you can have an application that's production worthy while being built on a compiler that's not quite there yet. The problem is, of course, you almost certainly didn't test anything near 100% and probably not even everything users may do with your software, so it's a risky bet.
losvedir 3y ago
If we're talking SemVer then 1.0 only means a commitment to a public interface. It doesn't mean the code has no more bugs and ready for use in a spaceship. Conversely, taking on a dependency prior to its 1.0 just means you're on the hook for dealing with API changes as they come up. But as long as the API you expose doesn't change, it's fine to be on 1.0 yourself.

by shemii 3y ago

fastball 3y ago

Bun is compiled to a binary, so not sure it matters how stable the underlying language is if Bun itself has a stable API?

KolmogorovComp 3y ago
That’s the point OP is making, even if the program is bug-free, given the compiler’s current state there’s a chance the compiled binary has bugs (due to miscompilation). Now that can happen with every compiler but using one in still in alpha significantly increases the risk.
- fastball 3y ago
  Does it help at all that Zig is LLVM-based?
  - wredue 3y ago
    Not particularly. And zig is moving away from llvm anyway.

kreetx 3y ago

Versioning isn’t an exact science, and people use whatever they see fit, both for technical but also marketing purposes.

brabel 3y ago

If you test your software built on Zig close to 100% then you can be pretty confident you didn't run into any of the Zig compiler bugs. Bun has certainly run into them but they can almost always be worked around... if you work around all problems and manage to catch everything then yeah, you can have an application that's production worthy while being built on a compiler that's not quite there yet. The problem is, of course, you almost certainly didn't test anything near 100% and probably not even everything users may do with your software, so it's a risky bet.

losvedir 3y ago

If we're talking SemVer then 1.0 only means a commitment to a public interface. It doesn't mean the code has no more bugs and ready for use in a spaceship. Conversely, taking on a dependency prior to its 1.0 just means you're on the hook for dealing with API changes as they come up. But as long as the API you expose doesn't change, it's fine to be on 1.0 yourself.