4 ms·

Despite the 1.0 release tag, given that it's written in Zig, which is super duper Alpha, I'd trust it only as far as I can throw a floppy with its source code.

by j-pb 3y ago

nifty_beaks 3y ago
I completely forgot it was written in Zig. Thanks for the heads up. I completely agree, I don't see how this can be labeled 1.0 release.
- math_dandy 3y ago
  I see it as a commitment to keep the public API stable.
- bobbylarrybobby 3y ago
  If they don't change the public API, they could rewrite it in Fortran for all I care.
  - j-pb 3y ago
    Fortran would at least have a reliable compiler.
c-hendricks 3y ago
I'd imagine a floppy would fly quite far when thrown like a frisbee tho
gfodor 3y ago
Fascinating, do you have literally any evidence whatsoever that this project doesn't work or isn't realiable?
- KolmogorovComp 3y ago
  A project can only be as reliable as its compiler. Zig currently suffers from a number of miscompilation [0] that is quite higher than for a more mature compiler. [0]: https://github.com/ziglang/zig/issues?q=is%3Aopen+is%3Aissue+label%3Amiscompilation https://github.com/ziglang/zig/issues?q=is%3Aopen+is%3Aissue...
  - wdb 3y ago
    That would mean you can't use LLVM either. Similar issues exists there: https://github.com/llvm/llvm-project/labels/miscompilation https://github.com/llvm/llvm-project/labels/miscompilation
    - computing 3y ago
      this is the most HN thread ever
dudus 3y ago
Why would it matter to you as a user, which language it was used before it was compiled to the machine code you run?
- bryancoxwell 3y ago
  Changes to Zig could force changes to Bun, and changes to Zig are all but guaranteed.
  - generichuman 3y ago
    It could force changes to Bun _internals_, which doesn't really affect users if the Bun team does not want to break API.
    - bryancoxwell 3y ago
      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.
      - slotrans 3y ago
        As an example, Java does just fine at guaranteeing its own semantics completely independently of what happens to C++.
        gingerrr 3y ago
        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.
        pseg134 3y ago
Thaxll 3y ago
For the end user it does not matters though it's kind of a detail of implementation.
- j-pb 3y ago
  It matters plenty if your production system goes down because of bugs caused by miscompilation of your js runtime. This level of instability doesn't uphold the social contract that a 1.0 implies.
- bottlepalm 3y ago
  It does worry me as a potential adopter of Bun what the long term outlook of the project is if the language used to write Bun isn't very accessible to prospective open source contributors.
  - AndyKelley 3y ago
    You seem to be implying that zig is not open source or is otherwise unfriendly to contributions...? It's a 501(c)(3) non profit and has been open source since `git init`. Even the financials are transparent to the public. What else could we possibly do?
    - bottlepalm 3y ago
      Zig being a language that most people are not familiar with is a very high barrier of entry in it of itself. Given how few projects are written in it, the ROI of learning it is not that great. I'm not 'against' Zig, it's just basic Lindy effect stuff. People don't want to build or invest in a foundation and then left hung out to dry. Just like the rest of my development choices, I try to take calculated risk so that the platforms I'm building on have a high chance of lasting into the future. We all know that a rewrite due to obsolescence can be the death knell for a project.
      - rhodysurf 3y ago
        I’ve used zig for like a week total in my life and during that time I had a PR accepted to the main repo. It’s very much friendly to contributors.
Matthias247 3y ago
I don't have any opinion on Bun itself. But as someone who is pretty experienced in running large scale services, I wouldn't have a problem to use a tool that is marked as stable but internally built on top of unstable tools. As long as compilation is mostly deterministic (which is usually given for compilers), a good set of unit and integration tests should prove that the software is actually doing what its supposed to do and can be trusted with workloads. If those tests are not available, then even using a mature language might not provide a guarantee that the actual product is better. Sure - the Bun developers might have a super hard time if Zig changes its syntax, library APIs or other things. But that would be a maintenance hassle for the Bun developers, and not necessarily for the Bun users.

Despite the 1.0 release tag, given that it's written in Zig, which is super duper Alpha, I'd trust it only as far as I can throw a floppy with its source code.

by j-pb 3y ago

Despite the 1.0 release tag, given that it's written in Zig, which is super duper Alpha, I'd trust it only as far as I can throw a floppy with its source code.

nifty_beaks 3y ago

I completely forgot it was written in Zig. Thanks for the heads up. I completely agree, I don't see how this can be labeled 1.0 release.

math_dandy 3y ago
I see it as a commitment to keep the public API stable.
bobbylarrybobby 3y ago
If they don't change the public API, they could rewrite it in Fortran for all I care.
- j-pb 3y ago
  Fortran would at least have a reliable compiler.

c-hendricks 3y ago

I'd imagine a floppy would fly quite far when thrown like a frisbee tho

gfodor 3y ago

Fascinating, do you have literally any evidence whatsoever that this project doesn't work or isn't realiable?

KolmogorovComp 3y ago
A project can only be as reliable as its compiler. Zig currently suffers from a number of miscompilation [0] that is quite higher than for a more mature compiler. [0]: https://github.com/ziglang/zig/issues?q=is%3Aopen+is%3Aissue+label%3Amiscompilation https://github.com/ziglang/zig/issues?q=is%3Aopen+is%3Aissue...
- wdb 3y ago
  That would mean you can't use LLVM either. Similar issues exists there: https://github.com/llvm/llvm-project/labels/miscompilation https://github.com/llvm/llvm-project/labels/miscompilation
  - computing 3y ago
    this is the most HN thread ever

dudus 3y ago

Why would it matter to you as a user, which language it was used before it was compiled to the machine code you run?

bryancoxwell 3y ago
Changes to Zig could force changes to Bun, and changes to Zig are all but guaranteed.
- generichuman 3y ago
  It could force changes to Bun _internals_, which doesn't really affect users if the Bun team does not want to break API.
  - bryancoxwell 3y ago
    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.
    - slotrans 3y ago
      As an example, Java does just fine at guaranteeing its own semantics completely independently of what happens to C++.
      - gingerrr 3y ago
        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.
        pseg134 3y ago

Thaxll 3y ago

For the end user it does not matters though it's kind of a detail of implementation.

j-pb 3y ago
It matters plenty if your production system goes down because of bugs caused by miscompilation of your js runtime. This level of instability doesn't uphold the social contract that a 1.0 implies.
bottlepalm 3y ago
It does worry me as a potential adopter of Bun what the long term outlook of the project is if the language used to write Bun isn't very accessible to prospective open source contributors.
- AndyKelley 3y ago
  You seem to be implying that zig is not open source or is otherwise unfriendly to contributions...? It's a 501(c)(3) non profit and has been open source since `git init`. Even the financials are transparent to the public. What else could we possibly do?
  - bottlepalm 3y ago
    Zig being a language that most people are not familiar with is a very high barrier of entry in it of itself. Given how few projects are written in it, the ROI of learning it is not that great. I'm not 'against' Zig, it's just basic Lindy effect stuff. People don't want to build or invest in a foundation and then left hung out to dry. Just like the rest of my development choices, I try to take calculated risk so that the platforms I'm building on have a high chance of lasting into the future. We all know that a rewrite due to obsolescence can be the death knell for a project.
    - rhodysurf 3y ago
      I’ve used zig for like a week total in my life and during that time I had a PR accepted to the main repo. It’s very much friendly to contributors.

Matthias247 3y ago

I don't have any opinion on Bun itself. But as someone who is pretty experienced in running large scale services, I wouldn't have a problem to use a tool that is marked as stable but internally built on top of unstable tools. As long as compilation is mostly deterministic (which is usually given for compilers), a good set of unit and integration tests should prove that the software is actually doing what its supposed to do and can be trusted with workloads. If those tests are not available, then even using a mature language might not provide a guarantee that the actual product is better. Sure - the Bun developers might have a super hard time if Zig changes its syntax, library APIs or other things. But that would be a maintenance hassle for the Bun developers, and not necessarily for the Bun users.