Should have called it Bunz!
Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
51–60 of 202 posts
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#52Here’s my idea.
DinnerRoll
Bun in D!
If someone with an MBA wants to raise capital we can start next Tuesday!
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#53Earlier quoted context omitted.
LLMs are as good as the operator directing them.
I'd say as thorough rather than good. Skilled engineers may still vibe and not care. Beginners may be thorough and experiment and ask till they get the design right even if they don't spot it immediately, just caring does a lot.
I agree with you about “thoroughness” being key here, but I’d additionally advocate that we need to leave room for people to make some slop learn it.
Part of the learning process, whether you’re a “skilled” or “unskilled” engineer (or not an engineer at all, and noting that going from one to the other is just a matter of learning), is being able to “vibe and not care.” Yes, it’s also helpful to identify things that might not work out theoretically in advance, using the things we learn in our CS programs. But coding with LLMs is a brand new modality, and we are all indeed just learning to work with them.
I think alternating vibe coding with vibe-assisted DRYing/cleaning is ultimately a workflow enhancer that can make better software faster. But engineers have to be allowed to make some slop to learn it.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#54Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#55This is what I like to call performative performance programming. I _LOVE_ performance as much as the next guy. And build times should be as close to 0 seconds as possible. But this is approaching diminishing returns and I guarantee that your CURRENT bottleneck is not build times.
The people who originally worked on Bun themselves would disagree with your point (but their situation was based on the premise that they did not take the steps required to leverage incremental compilation): https://zackoverflow.dev/writing/i-spent-181-minutes-waiting...
And, unrelated to Bun, I too would disagree. You don't want to have to wait minutes for a build to complete before you can run the test suite, or even just know if there was a semantic error in your code. Build times are 100% a bottle neck for big-enough projects.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#56> 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'…
The Zig compiler compiles lazily and does not detect dead code. (Read: functions that are not called from any compiled functions)
That makes total sense (though it would be nice if it could do that detected, I suppose), but what makes less sense to me is the accumulation of unnecessary code (and presumably unit tests for that code) that isn't removed as soon as it's no longer needed.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#57To me the most interesting fact about this fork is that it has proven that Bun could have had fast builds all along. To be fair, there are caveats still in place today: Zig incremental compilation does not yet support aarch64 and only the linux linker supports binary patching, but it's just a matter of time before all major platforms are conquered.
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.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#58I'd also like to see a (kind of) opposite approach: a fork of zig using only AI contributions. This is more as conceptual art or an experiment, rather than because I strongly support AI. But it would be fun to see how the two projects evolved....
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#59Now that no one cares about JS frontend framework, we moved the drama over to JS tooling written in other languages.
One reason I find deno nicer is that the node creator is solid isn't a slopperoo yapping about LLM induced quasi-productivity.
Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds
#60Why is there so much buzz around bun? Can't we just go back to node + npm + vitest + vite?
At this point, I'm not sure anyone should still be using npm.
Seriously. The only way to use it is to be a very religious person. You have to pray every single time you use it that your system doesn't become compromised.