Curious if anyone has an article about the zig version of Bun as an example of design/implementation that falls into the “needs improvement” category. Just looking for technical information about specific “what not to do” as examples from a large project.
I think Andrew’s recent post and Loris’s slightly earlier one about assertions provide technical critiques of Bun-in-Zig. I’m not sure if that’s what you’re looking for?
We are here to build things that people want and build them well. In the AI bubble, we are pressured to build things nobody wants, poorly. Pop the bubble.
sadly, i’m not sure if there even is a bubble. seems like a poison with a ton of bubbles spread everywhere.
exhibit: 98,493,134: ai slop by robobun · Pull Request #33864 · oven-sh/bun · GitHub
bots saying looks good to me, then nuked the issue because they identified their own AI Slop 
My favorite comment from the thread:
Hell is empty and all the devils are here
Really just looking for any memory errors they couldn’t fix (assuming that was a problem)
it sounds like it was a problem for Bun. I’m not sure if any measures were taken to try and avoid them. ime in most cases defer deinit immediately after creation is plenty. interacting with a VM is definitely a place where exceptions to the rule abound, of course…
This is a great take. I especially liked how the author pointed out the contradictory position on style guide enforcement! The subtext there is that Oven is more comfortable managing the unreliability of LLMs than they are managing the unreliability of humans. A classic anti-labour line.
All of this is covered in the original bun blog post.
Jarred never claimed they couldn’t fix them, just that it was a constant game of whack-a-mole. The first section of the post has a list of the kinds of issues they were routinely chasing.
Again, there’s a section in the blog dedicated to this.
For Bun, correctly handling the lifetimes of garbage-collected values and manually-managed values has been a major source of stability issues - most often small memory leaks and occasionally, crashes. Every memory allocation has to be meticulously reviewed. Where do these bytes get freed? How do we ensure it only gets freed once? Did we check for JavaScript exceptions properly? Is this garbage-collected pointer visible to the conservative stack scanner? Is this garbage collected memory or manually managed memory?
Note that I could have just copy the sited text, but in the spirit of AI discussion why not be wasteful and add a screenshot, I apologise to the site for this unnecessary extra bytes in your servers just to make a joke.
People are honestly making a bigger deal out of the Bun situation than it is. Does a software maintainer have to justify whatever change they are making to their software? I don’t think so. They might explain to help their users understand. I have no idea why is a person, who likely uses neither Bun nor Zig, writing about this. And quoting TigetStyle just shows how they are not understanding what does it take to glue so many components with different runtime expectations.
I agree that this topic is out of proportion, and somewhat that authors of software may not need to explain their decisions to the people that are running their software. With the rest I just don’t agree, but what you’re saying is also your opinion so…