Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

ziggit.dev

Post reply on HN
Print view View original

181–190 of 202 posts

Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

#181

Post by ozgrakkurt »

kristoff_it wrote: post #17

To 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.

This is an example of technical problems being easy but organization being hard imo. It is stupid if you think about it from a theoretical perspective but they didn’t want to use this feature for some reason.

Probably because they did their fork of zig for fast compilation before and they didn’t want to just discard it and use this

Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

#182

Post by maccard »

owaislone wrote: post #123
maccard wrote: post #122

Earlier quoted context omitted.

I would tell my co worker “this code has so many issues that I’m not actually reviewing it. Please make sure it meets the project standards before sending it back to me”if it happened twice I’d talk to their manager.

Sure - define your project standards in the repo or agent's skill and tell it just that.

See my other comment here [0] - I’ve not found it possible to actually have the agents follow the explicit instructions. Even single shot tasks once the context window fills up (which it does, very very fast, and repeatedly if you use subagents) will ignore very explicit instructions.

[0] https://news.ycombinator.com/item?id=49036222

Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

#183

Post by maccard »

nateb2022 wrote: post #140
maccard wrote: post #22

Earlier 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.

OP here - no AI used in the writing of any of my replies on this site. iOS does this when quoting [0]. I don’t think it’s in the spirit of this site to jump on me rather than the content of my comment either way.

[0] https://apple.stackexchange.com/questions/299505/ios-11-defa...

Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

#184

Post by owaislone »

maccard wrote: post #182
owaislone wrote: post #123

Earlier quoted context omitted.

Sure - define your project standards in the repo or agent's skill and tell it just that.

See my other comment here [0] - I’ve not found it possible to actually have the agents follow the explicit instructions. Even single shot tasks once the context window fills up (which it does, very very fast, and repeatedly if you use subagents) will ignore very explicit instructions. [0] https://news.ycombinator.com/item?id=49036222

- discuss the plan, dos-and-donts, instructions and have them add it to a PLAN_FEATURE.md with the goal, non-goal, non-negotiables, technical details on the top. - come up with phases to implement your thing. P1, P2, ... P8.. whatever - in each phase add simple one line TODOs with as much explanantion of the task as needed e.g, - [ ] Update DB schema, - [ ] Generate migrations - Ask the agent to go one phase or todo at a time depending on complexity. - if the context fills up, /clear the window and just ask it to do the next line. - if you wrote up all you care about in the plan properly, it'll follow what you need it to do.

Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

#185

Post by [deleted] »

Dylan16807 wrote: post #175
skeledrew wrote: post #94

Earlier quoted context omitted.

You should give the article[0] a read. "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,00…

I'm optimistic for that refactoring. But if one in 30 lines sprinkled all over everywhere is unsafe then you haven't actually done much to improve safety. When you have a large percent of fully safe functions and modules, that's when you're making a difference. Counting the lines is not a very helpful metric.

[deleted]

Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

#186

Post by [deleted] »

robertlagrant wrote: post #37

> 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'…

[deleted]

Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

#187

Post by brabel »

softwaredoug wrote: post #121

This effort makes me think of the tick-tock oscillation between features and code stewardship I’ve experienced on every agent heavy coding project Tick: go hard after features, build a correct and extremely messy version Tock: digest what was done, deslopify, improve project aspects that go beyond feature correctness: performance, maintainability, general fragility / sensitivity to change My experience is spending a…

> You sort of did this pre-AI

No, I did the opposite. First refactor the code base to make a new feature fit naturally in it later on. Then hopefully the new feature is easy to implement cleanly and correctly first time. The only times I’ve had to go back and do things again “properly” was when the feature itself was not designed properly or didn’t fit at all even after I tried to adapt it to fit which happens rarely, and mostly for experimental things that no one knows exactly how they should work.

Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

#188

Post by brabel »

nextaccountic wrote: post #68
kristoff_it wrote: post #55

Earlier quoted context omitted.

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 ev…

> TLDR; The Zig compiler takes about 1 minute and 30 seconds to compile debug builds of Bun. Zig's language server doesn't do basic things like type-checking, so often have to run the compiler to see if my code works. 90 seconds to less than 1 second. That's astonishing

It’s not so astonishing when you mention that incremental compilation has been only recently added to Zig and is still experimental. This astonishing change, if I understand it correctly, is achieved simply by migrating to the latest version of Zig and enabling this experimental feature.

Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

#189

Post by formerly_proven »

voidmain wrote: post #171
atombender wrote: post #111

Earlier quoted context omitted.

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).

The safety of safe rust is created by extremely strong and subtle invariants that unsafe rust must maintain perfectly (or all bets are off). The idea that a program with tens of thousands of lines of vibe coded unsafe Rust is memory safe is mind boggling.

IME agents are extremely happy to write more or less convincing // SAFETY: comments (most Rust code in the training set has these just before unsafe { - also it often works in unit tests). However, miri remains broadly unimpressed by comments.

Re: Buz – A fork of Bun using modern Zig, with sub-1s incremental builds

#190

Post by janpio »

kristoff_it wrote: post #17

To 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.

Do the caveats mean that it could _not_ actually have had fast builds on all the platforms it supports? (Honestly asking if I connected the dots correctly here, this is not a snarky "actually" rethorical question...)
Post reply on HN