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.
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.
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.
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
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.
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
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).
I was using node-fetch and fastify but I decided to remove node-fetch to just use global.fetch and everything broke.
Turns out node-fetch and fastify uses require("stream").ReadableStream, but global.fetch() uses require("stream/web").ReadableStream (because it is a web standard). Took me a few hours to figure out why it wasn't working, getting some "ReadableStream is not a ReadableStream" error is very fun to troubleshoot
I don't know what approach Bun should take in this regard, but I would like to see NodeJS deprecating non-standards as much as possible so eventually this problem can go away. ECMA should also standardise things required for server-side code more
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!"
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.
One difference is that Deno, and presumably those hundreds of other companies, have a pricing page. Whereas bun could easily be mistaken for just another open-source project.
What's their point? That they should not be open source? Or should not be allowed to ever launch a paid product? Or be forced to add a pricing page that...goes nowhere?
The point is that Deno has already a plan to monetize and they haven't, which puts a lot of doubt into if they will ever manage to and whether that will affect existing projects which rely on the runtime.
Deno has already monetized. Their tech powers many of the "serverless" platforms offered by other hosts. Just because they don't have a public pricing page for B2C doesn't mean they don't make money.
My point is that they could be transparent about the fact that they're collecting users along the way to extracting money from them. They chose not to. That's concerning to me. Possible explanations include "they have no idea what they're doing" and "they know exactly what they're doing but think people won't like it".
As the rest of your hyperventilation, no, none of those are my points, and I think you were smart enough to figure that out without me having to say so.
> collecting users along the way to extracting money from them
Can you listen to yourself?
When was the last time you paid Node or npm inc? Projects have the absolute right to monetize without having to start that way. You can use bun without signing up, there’s no data, there’s no registration. There are only entitled users.
I'm not a JS person, so never. But the first has a foundation, and the second has a transparent revenue model.
Bringing up rights is a straw man. They have a right to conceal their plans. I have a right to criticize them for it. You have the right to do defensive, awkward, unpaid PR for people who have millions of dollars. All rights are being honored here.
Wow didn't know they took a loan of $7 million dollars. That is an insane amount for a runtime without market adoption. Another one of those 2021 VC play I guess.
Possibly unpopular opinion – don't look to work at a <10 person startup if you don't want to put in those kind of hours. There are plenty of companies out there that will give you a great work life balance, fixed responsibilities, low pressure, big paychecks and more, and the trade off is that you won't get a chance at a 100x exit a few years down the line. You have to pick one of the two.
Eh. If you talk with second-time founders, a really common theme is how inefficient in retrospect the work-all-the-time phase was and how they want to do it differently.
I don't have a lot of data on current <10 person startups, so maybe it's all different now. But the times I was working 80-100 hour weeks were just not time well spent. It was not, "How can I deliver the most in the time I have?" It was "OMG pressure makes me so anxious I'm going to work all the time to avoid thinking about the stakes." It was more drama than effectiveness.
Your opinion is probably popular among its audience, but really that’s a shame. There’s a wealth of evidence that such an investment in hours is either counterproductive or short lived or both. The human impact can be devastating. The reward can be somewhere between fleeting and extremely deleterious.
I’m a former workaholic who put in countless 60-100 hour weeks, and mostly I made that choice on my own, but I sincerely wish I had heeded the warnings sooner. My 60-100 hour weeks weren’t 50-150% more productive, ever. They were just exhausting, maybe permanently.
There are good reasons to avoid putting in 80 hour weeks but doing so because someone who put in 100 hour weeks had a bad experience isn't one of them. The level of stress isn't linear as the weekly number of hours increases.
> someone who put in 100 hour weeks had a bad experience isn't one of them
I wasn’t so much trying to make my example a reason, as to say that I relate my own experience to the wealth of evidence.
> The level of stress isn't linear as the weekly number of hours increases.
This is true, and I definitely can relate to that as well. And I’d still feel the same way, now, if I’d only ever worked 50 hours in a week.
I’ll also add that the level of stress isn’t even consistent over multiple sustained weeks of the same level of overwork. When I even could work a 60 hour week, the second one in a row was much harder. The next one drastically harder still, and so on. And my probably-permanent burnout wasn’t from one particularly long week, it was from sustaining 60-100 hour weeks for about six months straight, with a lot of prior stressors, while developing a very strong internal rejection of sustaining anything like it while it was happening. In the end it was an action motivated by a sense of duty to address problems that put me in this position as fully as I could, so I could move on and never overwork for anyone or anything ever again.
But I’m cautious even saying all of that now, because any way I frame it suggests there’s an overwork compromise that might make sense. There isn’t. In hindsight, the first week I put too much of myself into work was one too many.
Ah, fair enough. Your opinion is still relevant. I would still like to hear from those that never exceeded 80 because there is a bit more of a chance they could have pulled it off.
Well sure, just like how there are technically no socialist tyrants and no communist tyrants and no capitalist tyrants. At the end of the day everyone can choose bits and pieces of what they want to believe in and ignore the rest.
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.
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)
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?
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).
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 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.
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?
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.
It's not about popularity. It's just I had a pain point (webpack gets slow on complex projects), and I discovered bun and it felt like it solved it, but it was very early days. Then, I discovered Vite which solves the pain point I had. Now I'm not looking for a solution because I am not in pain.
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 ."
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` ?
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.
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.
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
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
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.
83 comments
[ 2.6 ms ] story [ 105 ms ] threadHaving 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?
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.
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.
require("stream").Readable require("stream/web").ReadableStream
I was using node-fetch and fastify but I decided to remove node-fetch to just use global.fetch and everything broke.
Turns out node-fetch and fastify uses require("stream").ReadableStream, but global.fetch() uses require("stream/web").ReadableStream (because it is a web standard). Took me a few hours to figure out why it wasn't working, getting some "ReadableStream is not a ReadableStream" error is very fun to troubleshoot
I don't know what approach Bun should take in this regard, but I would like to see NodeJS deprecating non-standards as much as possible so eventually this problem can go away. ECMA should also standardise things required for server-side code more
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!"
As the rest of your hyperventilation, no, none of those are my points, and I think you were smart enough to figure that out without me having to say so.
Can you listen to yourself?
When was the last time you paid Node or npm inc? Projects have the absolute right to monetize without having to start that way. You can use bun without signing up, there’s no data, there’s no registration. There are only entitled users.
Bringing up rights is a straw man. They have a right to conceal their plans. I have a right to criticize them for it. You have the right to do defensive, awkward, unpaid PR for people who have millions of dollars. All rights are being honored here.
I don't have a lot of data on current <10 person startups, so maybe it's all different now. But the times I was working 80-100 hour weeks were just not time well spent. It was not, "How can I deliver the most in the time I have?" It was "OMG pressure makes me so anxious I'm going to work all the time to avoid thinking about the stakes." It was more drama than effectiveness.
And people have been saying so for a long time. E.g.: https://lostgarden.home.blog/2008/09/28/rules-of-productivit...
I’m a former workaholic who put in countless 60-100 hour weeks, and mostly I made that choice on my own, but I sincerely wish I had heeded the warnings sooner. My 60-100 hour weeks weren’t 50-150% more productive, ever. They were just exhausting, maybe permanently.
I wasn’t so much trying to make my example a reason, as to say that I relate my own experience to the wealth of evidence.
> The level of stress isn't linear as the weekly number of hours increases.
This is true, and I definitely can relate to that as well. And I’d still feel the same way, now, if I’d only ever worked 50 hours in a week.
I’ll also add that the level of stress isn’t even consistent over multiple sustained weeks of the same level of overwork. When I even could work a 60 hour week, the second one in a row was much harder. The next one drastically harder still, and so on. And my probably-permanent burnout wasn’t from one particularly long week, it was from sustaining 60-100 hour weeks for about six months straight, with a lot of prior stressors, while developing a very strong internal rejection of sustaining anything like it while it was happening. In the end it was an action motivated by a sense of duty to address problems that put me in this position as fully as I could, so I could move on and never overwork for anyone or anything ever again.
But I’m cautious even saying all of that now, because any way I frame it suggests there’s an overwork compromise that might make sense. There isn’t. In hindsight, the first week I put too much of myself into work was one too many.
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.
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)
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?
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).
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.
And following up on that, has anyone tried a Bun/Vite combo?
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.
% 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
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=... with sample code reproducing it? Happy to take a look
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
"Bun is a fast all-in-one JavaScript runtime"
Jarred previously mentioned it was worth a look: https://news.ycombinator.com/item?id=34431432
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.
https://github.com/oven-sh/bun/issues/43
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.
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