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.
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’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.
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...
Overall, I think the tech industry needs to do a better job of calling out the self-centered, narcissistic, libertarian, objectivist, wannabe billionaire, hustle culture types. These are the types of people who won't think twice about working on Facebook's algorithms to improve user engagement at the detriment of society and our mental health.
If you don't want to be banned, you're welcome to email [email protected] 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).