Why is there so much buzz around bun? Can't we just go back to node + npm + vitest + vite?
Breaking: JavaScript developers create three new frameworks/kits while you were reading this sentence.
Sir, 2010 was 16 years ago.
Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
141–150 of 202 posts
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#142Earlier quoted context omitted.
I don't understand - wouldn't this be observable by the person making the change? They used to call this function / use this class and now they don't any more? Even if it's inside a conditional compilation block.
i did not say "Impossible to detect"! in practice the exponential explosion of options may become intractable. lets say you have 10 compilation flags with 10 options each. not syre you want the compiler scanning through all that on each pass
Yes - I was only talking about when a person removes some code from use, removing the code as well as the call to the code. I wasn't meaning the compiler at all (although it would be nice if the compiler could autodetect it, as you say, that could become tricky).
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#143Earlier quoted context omitted.
After the all the noise surrounding the forking of the Zig compiler in order to speed up builds, I'm really surprised that this isn't the top comment. The fact that a one-man team achieved 1s build times proves pretty conclusively that slow build times were entirely result of negligent development practices, and that the fork was a complete misallocation of time.
A significant part of the port was also for the built-in safety. Unsafe code just... fails to compile. Turns out there's a journey here.
GP is talking about the fork of the Zig compiler, not the rewrite of Bun into Rust.
Anthropic submitted to patch the Zig compiler to improve Bun compilation times, it was rejected. One reason it was rejected is that it contained AI-generated code, which is against the community guidelines, but more importantly, it would have been rejected regardless of AI use. They claimed a 4x improvement, something like going from 2 minutes to 30 seconds, but, according to the Zig team, it made compilation non-deterministic, and missed on the real improvement they worked on, which was sub-1s incremental builds.
"Buz" shows that the fork submitted by Anthropic wasn't needed as Bun can now compile under 1s (incrementally), which is much better than the 30s they achieved with their patch.
It is likely that this rejection, especially the "no AI" aspect of it encouraged Anthropic to move away from Zig.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#144Earlier quoted context omitted.
A significant part of the port was also for the built-in safety. Unsafe code just... fails to compile. Turns out there's a journey here.
GP is talking about the fork of the Zig compiler, not the rewrite of Bun into Rust. Anthropic submitted to patch the Zig compiler to improve Bun compilation times, it was rejected. One reason it was rejected is that it contained AI-generated code, which is against the community guidelines, but more importantly, it would have been rejected regardless of AI use. They claimed a 4x improvement, something like going from…
Is there anything suggesting that Bun even attempted to submit their Zig patches? As far as I know, they were stuck 2 versions behind. With the amount of changes and Zig already working on incremental I'm not sure what the point would have been.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#145Earlier quoted context omitted.
The port was line for line and full of unsafe code. It didn't prevent any bugs. They're not using Rust for its strengths.
The original Zig code is metaphorically one big unsafe block. Even if the Rust port is made up of 3% unsafe blocks, that still means 97% of the original Zig code has been made safe (in the Rust sense).
Of note, even that 97% of original code that is now "safe in the rust sense" could violate invariants through safe blocks that cause memory-safety issues. I can't say exactly how the LLM-ported Rust code made use of unsafe but see https://www.ralfj.de/blog/2016/01/09/the-scope-of-unsafe.htm...
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#146Earlier quoted context omitted.
I’d say I fall in the “AI skeptic but willing to use it” category. If LLMs can actually clean up after themselves it would actually be a game changer.
I'm assuming based on the special unicode angled quote marks that this is copy/pasted from an AI? I don't understand why people would type a lot more into an AI just to copy a comment this short, which would be at least 10x faster to just type by hand.
Not sure about op but if I post here from my phone I get those. Example: “quoted string”
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#147Earlier quoted context omitted.
Only if you have a tiny screen. You can make them output what you would've written yourself, but that would be slower than writing it yourself, so no one does that - but it’s trivially true.
Well, we've been saying this about infinite monkeys too.
> infinite monkeys
Welcome to the dev community!
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#148Earlier quoted context omitted.
The pearl clutching about AI is insane to me, as if code quality was perfect before 2022. We have been seeing a decline in software quality for a long time coming now. A lot of AI hatred is not even based on seeing something genuinely bad, its just prejudice for the sake of prejudice. If I could view into two parallel worlds, one where I vibe code something, release it and tell people it's vibe coded, and another whe…
> "Hey, I know you're leaning on the AI a bit, but here's what's wrong with the code: ...." I'm generally in agreement, but I think current corporate/productivity culture and AI is a bad mix that makes this quote/sentiment feel impossible. All of the current incentives are set up to push out as much sloppy code as possible, and AI is the perfect machine for doing that in huge quantities, to the point where reviewing…
I do agree, if someone's just going to shove what you say to an AI at what point do you ask "do we need to replace you with a shell script?" before they stop being overtly reliant on AI, that's a bridge too far for me, and I am all for letting Claude hack away at code for a while, and then review the code and refine it, a lot of the time even if its not perfect, it gets me like 80 to 90% of the way there, especially if I tell it HOW I want it written, and to consider edge cases.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#149> I’ve cut over 11,000 lines of completely dead code from Bun. I can’t think of another project whose codebase was so neglected as to reach 11K lines of dead code. I’ve also rewritten and modernized parts of the codebase, trying to rely more on Zig’s stdlib. In the process, countless bugs have also been fixed. This is astonishing. Is anyone else surprised at this dead code figure? Is it a feature of large projects I'…
TFA says the whole codebase is 600k, so that would be 1.8% dead code. IME dead code is much more common in larger codebases as figuring out that code is dead becomes more non-local and changes over time create dead code at a distance. I'm also not sure if the 11k was trivially dead (`if (false) { dead_code(); }`) or if it was more subtle (e.g. dynamically-dispatchable code that can't logically be called). The 1.8% fe…
It was trivially dead
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#150> To that end, I’ve cut over 11,000 lines of completely dead code from Bun. I can’t think of another project whose codebase was so neglected as to reach 11K lines of dead code. How long has this person been programming?
Over a decade. I should've clarified, I meant "trivially dead" code that's not called by anything. Can you think of another project with that much?