6 ms·

I work on Bun. Happy to answer questions

by Jarred 4y ago

traviswt 4y ago
Do you have a guess when you’ll be stabilizing around 1.0, perhaps a roadmap?
- raydiatian 4y ago
  +1
- Jarred 4y ago
  I think we are 2 months out from a 1.0 release
  - traviswt 4y ago
    Exciting! Thanks for all your hard work!
codethief 4y ago
Congrats on the release! Having recently started coding in Zig, in no small part because of Bun, I would like to know: How do you deal with the fact that Zig is not a very stable language yet? I was surprised to find out that Andrew Kelley and his collaborators still consider breaking changes on a regular basis, that there quite a few bugs and, let's call them, unintentional inconveniences that will require further breaking changes to fix. More generally, how do you like Zig?
- hryx 4y ago
  I don't speak for Jarred or Andrew, but here is a recent exchange between them about this matter: https://github.com/ziglang/zig/issues/14542#issuecomment-1416885269 https://github.com/ziglang/zig/issues/14542#issuecomment-141... The tension is understandable: Zig is explicitly not production-ready, yet it has such attractive performance and productivity properties, and has even proven useful in production scenarios (Bun, Uber, Tigerbeetle). But Andrew's suggestion is correctly aligned with Zig's mission and current level of maturity. If you have a complex project with lots of users like Jarred does, stick with a tagged release for now. The highest priority of Zig pre-1.0 is to make the language the best it can be — which it will be in due time. The target audience of the master branch is those who can withstand churn and are focused on getting it there.
- dottedmag 4y ago
  I'm not affiliated with Bun either, however the my advice would be to freeze the Zig dependency, and treat Zig upgrade like you would treat any library update: do it explicitly.
rmorey 4y ago
do you foresee having to make more decisions that come down against web standards for the sake of node compatibility? any tough decisions on the roadmap? to be clear i think you made the right call, but i’m curious if you think this is going to be a recurring issue
- eyelidlessness 4y ago
  I can’t speak for Jarred or other Bun devs, but I think this has a pretty straightforward answer: if the goal is transparent support for packages written for Node (or some defined subset thereof), that inherently means bug/quirk/extension compatibility too (for whatever subset is being targeted). IMO (not strongly held, largely as a spectator so far), it’s probably a bad thing in the long run for Bun (and Deno, and other JS server/CLI runtimes) to be so beholden to Node compatibility. I’d much rather see these compatibility efforts devoted to isolating Node-specific considerations, with clear guidance on how to migrate existing projects to more portable APIs. Node has already shown positive signs of embracing portability as contenders have also done. In the short term “works with stuff written for Node” is very appealing, but in the long term “Node works for stuff written for standards” is much more appealing than that. The more each of these runtimes courts the former, the more the latter is protracted.
  - brundolf 4y ago
    This was the battle I was excited for Deno to take a hard stance on, but it seems like even they have been forced to make some compromises now. It still seems like they envision people moving (gradually instead of all at once) to more consistent and standardized practices, but it doesn't look like we get to cut off the long tail of compatibility after all
- Jarred 4y ago
  Recent versions of Node.js implement many web APIs. The ecosystem is converging on a mix of web APIs and Node.js APIs. Excluding a few cases (like setTimeout), this won’t be a recurring tradeoff for Bun's runtime APIs (module resolution, however, is complicated).
serverholic 4y ago
[flagged]
- dang 4y ago
  Your posts in this thread crossed not only into personal attack but harassment. Not only that, but you've done it before. Not only that, but you've been breaking the site guidelines in all kinds of ways and ignoring our previous requests to stop. I've therefore banned the account. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
- MuffinFlavored 4y ago
  hire? it's open source software for free, no?
  - pancrufty 4y ago
    No, there’s intention to monetize.
    - wpietri 4y ago
      Yeah, if you take $7m from YC and Kleiner Perkins, it is definitely not a charity operation: https://www.crunchbase.com/organization/oven/company_financials https://www.crunchbase.com/organization/oven/company_financi... It's a little concerning to me when something's commercial nature is so far in the background like this. I guess I've had too many years of, "Surprise, our business model is you!"
      - paxys 4y ago
        What's the surprise exactly? Deno works the same way, as do hundreds of other companies that give out an open source version of their software for free and provide hosting and support as paid services.
omani 4y ago
do you plan to provide an alpine package for bun?
- Jarred 4y ago
  We need to get a musl libc build of Bun to do it properly. The zig part of that is really easy, but we also need to build WebKit and all other dependencies with musl libc If you use glibc-compat, you can download Bun from the github releases and that should just work. In a docker image it's about 200 MB (bun's binary is around 90 MB right now, which is way too big imo)
  - rom-antics 4y ago
    > bun's binary is around 90 MB right now This made me curious, so I checked out bun's repo and it's 217k lines of Zig (ignoring the other languages). Can you share what Zig's build times are like for a project that size?
serverholic 4y ago
[flagged]
sroussey 4y ago
Loving bun! Best way to use typescript and have things “just work” as compared to node and node-ts and setting type:”module” in package.json and dealing with headaches. Some things to add: - duckbd embedded like sqlite - fix the stdout/stdin terminal issues so it can be used for fast CLI stuff (basic things like columns/rows count, rawMode, mouse, et all) - sub project to port electron apis so we can have a new, mostly compatible version of electron that uses bun for the headless processing and uses system webviews for front lens (no node integration).
toastal 4y ago
When will communications be bridged to Matrix, XMPP, and/or IRC instead of Discord lock-in?
truth_seeker 4y ago
Please create a feature parity page on Github so that the end user knows how far the latest releases of Bun is compatible with latest version of NodeJS API.

I work on Bun. Happy to answer questions

by Jarred 4y ago

I work on Bun. Happy to answer questions

traviswt 4y ago

Do you have a guess when you’ll be stabilizing around 1.0, perhaps a roadmap?

raydiatian 4y ago
+1
Jarred 4y ago
I think we are 2 months out from a 1.0 release
- traviswt 4y ago
  Exciting! Thanks for all your hard work!

codethief 4y ago

Congrats on the release! Having recently started coding in Zig, in no small part because of Bun, I would like to know: How do you deal with the fact that Zig is not a very stable language yet? I was surprised to find out that Andrew Kelley and his collaborators still consider breaking changes on a regular basis, that there quite a few bugs and, let's call them, unintentional inconveniences that will require further breaking changes to fix. More generally, how do you like Zig?

hryx 4y ago
I don't speak for Jarred or Andrew, but here is a recent exchange between them about this matter: https://github.com/ziglang/zig/issues/14542#issuecomment-1416885269 https://github.com/ziglang/zig/issues/14542#issuecomment-141... The tension is understandable: Zig is explicitly not production-ready, yet it has such attractive performance and productivity properties, and has even proven useful in production scenarios (Bun, Uber, Tigerbeetle). But Andrew's suggestion is correctly aligned with Zig's mission and current level of maturity. If you have a complex project with lots of users like Jarred does, stick with a tagged release for now. The highest priority of Zig pre-1.0 is to make the language the best it can be — which it will be in due time. The target audience of the master branch is those who can withstand churn and are focused on getting it there.
dottedmag 4y ago
I'm not affiliated with Bun either, however the my advice would be to freeze the Zig dependency, and treat Zig upgrade like you would treat any library update: do it explicitly.

rmorey 4y ago

do you foresee having to make more decisions that come down against web standards for the sake of node compatibility? any tough decisions on the roadmap? to be clear i think you made the right call, but i’m curious if you think this is going to be a recurring issue

eyelidlessness 4y ago
I can’t speak for Jarred or other Bun devs, but I think this has a pretty straightforward answer: if the goal is transparent support for packages written for Node (or some defined subset thereof), that inherently means bug/quirk/extension compatibility too (for whatever subset is being targeted). IMO (not strongly held, largely as a spectator so far), it’s probably a bad thing in the long run for Bun (and Deno, and other JS server/CLI runtimes) to be so beholden to Node compatibility. I’d much rather see these compatibility efforts devoted to isolating Node-specific considerations, with clear guidance on how to migrate existing projects to more portable APIs. Node has already shown positive signs of embracing portability as contenders have also done. In the short term “works with stuff written for Node” is very appealing, but in the long term “Node works for stuff written for standards” is much more appealing than that. The more each of these runtimes courts the former, the more the latter is protracted.
- brundolf 4y ago
  This was the battle I was excited for Deno to take a hard stance on, but it seems like even they have been forced to make some compromises now. It still seems like they envision people moving (gradually instead of all at once) to more consistent and standardized practices, but it doesn't look like we get to cut off the long tail of compatibility after all
Jarred 4y ago
Recent versions of Node.js implement many web APIs. The ecosystem is converging on a mix of web APIs and Node.js APIs. Excluding a few cases (like setTimeout), this won’t be a recurring tradeoff for Bun's runtime APIs (module resolution, however, is complicated).

serverholic 4y ago

[flagged]

dang 4y ago
Your posts in this thread crossed not only into personal attack but harassment. Not only that, but you've done it before. Not only that, but you've been breaking the site guidelines in all kinds of ways and ignoring our previous requests to stop. I've therefore banned the account. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html.
MuffinFlavored 4y ago
hire? it's open source software for free, no?
- pancrufty 4y ago
  No, there’s intention to monetize.
  - wpietri 4y ago
    Yeah, if you take $7m from YC and Kleiner Perkins, it is definitely not a charity operation: https://www.crunchbase.com/organization/oven/company_financials https://www.crunchbase.com/organization/oven/company_financi... It's a little concerning to me when something's commercial nature is so far in the background like this. I guess I've had too many years of, "Surprise, our business model is you!"
    - paxys 4y ago
      What's the surprise exactly? Deno works the same way, as do hundreds of other companies that give out an open source version of their software for free and provide hosting and support as paid services.

omani 4y ago

do you plan to provide an alpine package for bun?

Jarred 4y ago
We need to get a musl libc build of Bun to do it properly. The zig part of that is really easy, but we also need to build WebKit and all other dependencies with musl libc If you use glibc-compat, you can download Bun from the github releases and that should just work. In a docker image it's about 200 MB (bun's binary is around 90 MB right now, which is way too big imo)
- rom-antics 4y ago
  > bun's binary is around 90 MB right now This made me curious, so I checked out bun's repo and it's 217k lines of Zig (ignoring the other languages). Can you share what Zig's build times are like for a project that size?

serverholic 4y ago

[flagged]

sroussey 4y ago

Loving bun! Best way to use typescript and have things “just work” as compared to node and node-ts and setting type:”module” in package.json and dealing with headaches. Some things to add: - duckbd embedded like sqlite - fix the stdout/stdin terminal issues so it can be used for fast CLI stuff (basic things like columns/rows count, rawMode, mouse, et all) - sub project to port electron apis so we can have a new, mostly compatible version of electron that uses bun for the headless processing and uses system webviews for front lens (no node integration).

toastal 4y ago

When will communications be bridged to Matrix, XMPP, and/or IRC instead of Discord lock-in?

truth_seeker 4y ago

Please create a feature parity page on Github so that the end user knows how far the latest releases of Bun is compatible with latest version of NodeJS API.