Earlier quoted context omitted.
the fifth labour of Hercules was cleaning the Augean stables, which this undertaking seems very much alike
But Hercules eventually finished, I think what koolba is saying is this task can't be finished.
Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
91–100 of 202 posts
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#92Earlier quoted context omitted.
The error bars on that one are too large to fit on screen, but yes.
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.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#93Earlier 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.
LLMs can clean up after themselves if you steer them. It's not very hard. I often have a two-step dance I do where the LLM first outputs some code and then I prompt it to fix the types up to my standards. I haven't found a way to prompt it with any number of skills or CLAUDE.mds or anything else to get it to do it the way I want on the first pass, but it's not that hard to just fix it afterwards. It's a fast enough p…
My experience has been the opposite. I prompt it and it generates something that mostly works, but steering it into something that would actually be maintainable is an exercise in futility. GPT-5.5 uses up my entire allocation of tokens in just reading the context docs and doing a single shot task.
> aven't found a way to prompt it with any number of skills or CLAUDE.mds or anything else to get it to do it the way I want on the first pass, but it's not that hard to just fix it afterwards.
I've yet to find a way to get an LLM to actually follow the instructions in CLAUDE/Agents.md It very quickly gets to a point where it forgets explicit instructions such as "run clang-format on all .h/.cpp files that you touch", and saying "our coding standards can be found at , please ensure all code adheres strictly to this standard" is ignored. I'd also say that the first pass of the code is very often not even close to how it _should_ be implemented so it's not just review and patch up, it's rearchitect + restructure 50% of the code.
> it also rapidly starts changing things just to change things,
Agreed. LLM's are (very good) text generators. They are good for generating code, and left to their own devices they will generate and generate and generate. Getting them to edit, simplify, and foresee future problems is something that people keep saying "use the latest model, it's amazing (despite saying that about the last 3 models" or "you just need to use " or "your agents.md needs to contain XYZ" will solve.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#94Earlier 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.
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.
"A large percentage of bugs from that list are use-after-free, double-free, and "forgot to free" in an error path. In safe Rust, these are compiler errors and RAII-like automatic cleanup with Drop. Compiler errors are a better feedback loop than a style guide."
"At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library. I expect this number to go down over time as we refactor from a faithful Zig port (which had no greppable unsafe keyword) to idiomatic Rust, but we are going to continue using C & C++ libraries like JavaScriptCore so it will always have more unsafe than pure Rust projects."
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#95Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#96To call the Bun rewrite "quintessential slop" is all I need to know to not take this person or their project seriously.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#97Earlier 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.
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.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#98Why is there so much buzz around bun? Can't we just go back to node + npm + vitest + vite?
You're kind of stating the reason for the buzz there: one runtime that does everything you need rather than cobbling together a dozen different tools.
Not that there's a problem cobbling together different tools made to do a job, each tool has a purpose and solves a problem, but having all problems solved out of the box is very convenient.
Bun does offer an additional major advantage, i.e. the bundler has a runtime API, so the same process that serves your assets can also bundle them in memory without having to coordinate an external bundler writing static files to disk.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#99> 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…
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#100> 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'…
I'm astonished that anyone is astonished by this amount of dead code in any large code-base. That's like 10 somewhat normal sized PRs worth of code.
It's bog standard, very mild technical debt.