12 ms·

Bun v0.5.7

160 points by computing 4y ago

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.
itslennysfault 4y ago
I was really excited about Bun when it first launched and even joined the early beta and it blows the doors off most other options (webpack) for sure. However, I've discovered Vite since then, and I know it's not a 1:1 comparison, but Vite is much more mature, and does everything I need and is incredibly user friendly and plenty fast enough for me. I kinda feel like Bun missed its moment already. Someone convince me otherwise please. I'm loving Vite it's a huge step up from Webpack, and isn't leaving me wanting for anything more.
- trwired 4y ago
  Since Bun is a runtime for JavaScript, wouldn't Vite benefit from being run on top of it? My experience with Vite is that as the number of files in a project grow, it can slow down quite noticeably. And following up on that, has anyone tried a Bun/Vite combo?
  - e12e 4y ago
    Indeed... https://github.com/oven-sh/bun/issues/250 https://github.com/oven-sh/bun/issues/250
- 59nadir 4y ago
  >I kinda feel like Bun missed its moment already. While I'm not particularly into or even all that interested in Bun, this pop culture attitude in general always mystifies me. What's the purpose of adopting this attitude (or is it involuntary)? Even if Vite were to do exactly what Bun does, they could both still exist and the world would just move along as it did before. Something being popular or not doesn't matter if it solves something. I imagine people who have this attitude turn into people who never actually try out anything for fear of using something that less than 5% of developers use. Most actually good things I know are used by far less than even that and they solve real problems for me. P.S. I would argue popularity hasn't helped JavaScript one bit: it's barely improving at all and most of the ecosystem is still a massive pain to use, most of the libraries are awful, performance is still lacking and basics like threading are still not solved. The popularity only helps with getting people into the churn and that's a dubious goal at best. Most of these points apply to Python as well.
cyclecity 4y ago
Also, bun has docs now: https://bun.sh/docs https://bun.sh/docs
- brrrrrm 4y ago
  Huge! Congrats team and Colin in particular :)
thedumbname 4y ago
Is it expected to work in the real world? I don't think so % bun test bun test v0.5.7 (5929daee) 17 | expect([...] ^ error: Not implemented error: Unexpected ? ?PNG ^ [...]/a.png:1:1 0 zsh: segmentation fault bun test
- Jarred 4y ago
  Sorry about this It looks like some code is importing a .png file and then some other issue (likely related to that) is causing a crash in the test runner Can you file an issue on https://github.com/oven-sh/bun/issues/new?assignees=&labels=bug&template=2-bug-report.yml https://github.com/oven-sh/bun/issues/new?assignees=&labels=... with sample code reproducing it? Happy to take a look
korginator 4y ago
It would help to say a few words in the submission about what bun is supposed to be and why anyone should care. The name sounds like a recipe app or something for my culinary experience. From the docs [1], "Bun is an all-in-one toolkit for JavaScript and TypeScript apps. It ships as a single executable called bun ." [1] https://bun.sh/docs https://bun.sh/docs
- thunderbong 4y ago
  This is a release page. Clicking on the main icon gives the home page with this as the first line - "Bun is a fast all-in-one JavaScript runtime"
- hknmtt 4y ago
  i guess it is a standalone V8 equivalent that can simply compile and run javascript you give it it. not sue how it differs to nodejs though.
1vuio0pswjnm7 4y ago
Any news on musl support? Jarred previously mentioned it was worth a look: https://news.ycombinator.com/item?id=34431432 https://news.ycombinator.com/item?id=34431432
0ldT1m3r 4y ago
I've been trying to get bundling working with bun without success using `bun bun`. It just crashes or hangs. Is there an way to get bun to work like `esbuild --bundle` ?
- Jarred 4y ago
  I suggest not using bun bun right now and trying again after Bun v0.6. We are working on a rewrite of the bundler. The current implementation only bundles node_modules (meaning it doesn’t behave like esbuild —bundle), doesn’t correctly handle a number of cases with ESM <> CJS interop, and doesn’t produce compact or optimized output. Fixing this is one of the top priorities right now.
2h 4y ago
no Windows: https://github.com/oven-sh/bun/issues/43 https://github.com/oven-sh/bun/issues/43
IshKebab 4y ago
How does Bun compare to Deno? I guess that's their main competition?
- killingtime74 4y ago
  Bun is not production ready, Deno is. Deno is written in Rust and used V8. Bun is written in Zig and uses JavaScriptCore.
  - cfuendev 4y ago
    The way I see it, Deno was built to be an executable, Typescript-first, Web API first and have a robust security model. Bun is built to be an executable and blazingly fast while still learning from some of Deno's hits and misses.
    - httgp 4y ago
      Bun also does way more. It aims to be an all-in-one runtime, so it has way more, even a planned bundler.
      - Alifatisk 4y ago
        That’s huge
sroussey 4y ago
How does Bun’s GC work? I have a CLI ghat does some processing and Bun used all the memory and pushed me deep into swap on a 64gb ram machine. I added some Bun.sleep(1) in the some loops to give the GC more time but that didn’t help much.
- Jarred 4y ago
  This sounds like a GC scheduling bug in Bun For now, try doing Bun.gc() and if that doesn’t help enough, try Bun.gc(true). This isn’t a great solution because it will make your code slower The GC schedules automatically on event loop tasks and in a few other points in the lifecycle of the application. It is not yet scheduling under memory pressure events and I think that’s what’s missing here
  - bin_bash 4y ago
    wouldn't that happen on Bun.sleep(1)?
    - Jarred 4y ago
      Yes, but the GC needs to be scheduled quite a lot for it to work as expected
      - sroussey 4y ago
        And since SQLite is synchronous, no time is available!
- bhaney 4y ago
  Are you sure you don't just have a memory leak in your code? Even in javascript, if you're accidentally keeping accessible references to objects you aren't intending to access again, they can't be freed by the gc
  - sroussey 4y ago
    No, it’s a single loop loading from one db table and into another (transformed).
turbobooster 4y ago
I'm concerned with how much debt they have and if they don't pay it back. Deno seems safer.

Bun v0.5.7

160 points by computing 4y ago

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.

itslennysfault 4y ago

I was really excited about Bun when it first launched and even joined the early beta and it blows the doors off most other options (webpack) for sure. However, I've discovered Vite since then, and I know it's not a 1:1 comparison, but Vite is much more mature, and does everything I need and is incredibly user friendly and plenty fast enough for me. I kinda feel like Bun missed its moment already. Someone convince me otherwise please. I'm loving Vite it's a huge step up from Webpack, and isn't leaving me wanting for anything more.

trwired 4y ago
Since Bun is a runtime for JavaScript, wouldn't Vite benefit from being run on top of it? My experience with Vite is that as the number of files in a project grow, it can slow down quite noticeably. And following up on that, has anyone tried a Bun/Vite combo?
- e12e 4y ago
  Indeed... https://github.com/oven-sh/bun/issues/250 https://github.com/oven-sh/bun/issues/250
59nadir 4y ago
>I kinda feel like Bun missed its moment already. While I'm not particularly into or even all that interested in Bun, this pop culture attitude in general always mystifies me. What's the purpose of adopting this attitude (or is it involuntary)? Even if Vite were to do exactly what Bun does, they could both still exist and the world would just move along as it did before. Something being popular or not doesn't matter if it solves something. I imagine people who have this attitude turn into people who never actually try out anything for fear of using something that less than 5% of developers use. Most actually good things I know are used by far less than even that and they solve real problems for me. P.S. I would argue popularity hasn't helped JavaScript one bit: it's barely improving at all and most of the ecosystem is still a massive pain to use, most of the libraries are awful, performance is still lacking and basics like threading are still not solved. The popularity only helps with getting people into the churn and that's a dubious goal at best. Most of these points apply to Python as well.

cyclecity 4y ago

Also, bun has docs now: https://bun.sh/docs https://bun.sh/docs

brrrrrm 4y ago
Huge! Congrats team and Colin in particular :)

thedumbname 4y ago

Is it expected to work in the real world? I don't think so % bun test bun test v0.5.7 (5929daee) 17 | expect([...] ^ error: Not implemented error: Unexpected ? ?PNG ^ [...]/a.png:1:1 0 zsh: segmentation fault bun test

Jarred 4y ago
Sorry about this It looks like some code is importing a .png file and then some other issue (likely related to that) is causing a crash in the test runner Can you file an issue on https://github.com/oven-sh/bun/issues/new?assignees=&labels=bug&template=2-bug-report.yml https://github.com/oven-sh/bun/issues/new?assignees=&labels=... with sample code reproducing it? Happy to take a look

korginator 4y ago

It would help to say a few words in the submission about what bun is supposed to be and why anyone should care. The name sounds like a recipe app or something for my culinary experience. From the docs [1], "Bun is an all-in-one toolkit for JavaScript and TypeScript apps. It ships as a single executable called bun ." [1] https://bun.sh/docs https://bun.sh/docs

thunderbong 4y ago
This is a release page. Clicking on the main icon gives the home page with this as the first line - "Bun is a fast all-in-one JavaScript runtime"
hknmtt 4y ago
i guess it is a standalone V8 equivalent that can simply compile and run javascript you give it it. not sue how it differs to nodejs though.

1vuio0pswjnm7 4y ago

Any news on musl support? Jarred previously mentioned it was worth a look: https://news.ycombinator.com/item?id=34431432 https://news.ycombinator.com/item?id=34431432

0ldT1m3r 4y ago

I've been trying to get bundling working with bun without success using `bun bun`. It just crashes or hangs. Is there an way to get bun to work like `esbuild --bundle` ?

Jarred 4y ago
I suggest not using bun bun right now and trying again after Bun v0.6. We are working on a rewrite of the bundler. The current implementation only bundles node_modules (meaning it doesn’t behave like esbuild —bundle), doesn’t correctly handle a number of cases with ESM <> CJS interop, and doesn’t produce compact or optimized output. Fixing this is one of the top priorities right now.

2h 4y ago

no Windows: https://github.com/oven-sh/bun/issues/43 https://github.com/oven-sh/bun/issues/43

IshKebab 4y ago

How does Bun compare to Deno? I guess that's their main competition?

killingtime74 4y ago
Bun is not production ready, Deno is. Deno is written in Rust and used V8. Bun is written in Zig and uses JavaScriptCore.
- cfuendev 4y ago
  The way I see it, Deno was built to be an executable, Typescript-first, Web API first and have a robust security model. Bun is built to be an executable and blazingly fast while still learning from some of Deno's hits and misses.
  - httgp 4y ago
    Bun also does way more. It aims to be an all-in-one runtime, so it has way more, even a planned bundler.
    - Alifatisk 4y ago
      That’s huge

sroussey 4y ago

How does Bun’s GC work? I have a CLI ghat does some processing and Bun used all the memory and pushed me deep into swap on a 64gb ram machine. I added some Bun.sleep(1) in the some loops to give the GC more time but that didn’t help much.

Jarred 4y ago
This sounds like a GC scheduling bug in Bun For now, try doing Bun.gc() and if that doesn’t help enough, try Bun.gc(true). This isn’t a great solution because it will make your code slower The GC schedules automatically on event loop tasks and in a few other points in the lifecycle of the application. It is not yet scheduling under memory pressure events and I think that’s what’s missing here
- bin_bash 4y ago
  wouldn't that happen on Bun.sleep(1)?
  - Jarred 4y ago
    Yes, but the GC needs to be scheduled quite a lot for it to work as expected
    - sroussey 4y ago
      And since SQLite is synchronous, no time is available!
bhaney 4y ago
Are you sure you don't just have a memory leak in your code? Even in javascript, if you're accidentally keeping accessible references to objects you aren't intending to access again, they can't be freed by the gc
- sroussey 4y ago
  No, it’s a single loop loading from one db table and into another (transformed).

turbobooster 4y ago

I'm concerned with how much debt they have and if they don't pay it back. Deno seems safer.