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

Rewriting Bun in Rust

bun.com

Post reply on HN
Print view View original

381–390 of 560 posts

Re: Rewriting Bun in Rust

#381

Post by xyzsparetimexyz »

> I asked Claude to loop the workflow on all 1,448 .zig files, and about 2 minutes in, one Claude ran git stash before committing. Another ran git stash pop. And then git reset HEAD --hard. They were stepping on each other!

I hate how easy git makes it for llms to catastrophically fuck up repos

> And if I put each Claude into a separate worktree, I would run out of disk space because Bun's git repository is too big and eventually the changes will need to be compiled and seen together.

This seems like a stupidly easy problem to fix.

> So, I asked Claude to edit the workflow to instruct Claude to never run git stash or git reset or any git command that doesn't commit a specific file at once. No cargo either. No slow commands at all.

What's the right way to fix this? I have a Pi extension that blocks any use of the word 'git' with 'stash/checkout/reset/restore' in commands which is a very large hammer approach. Is there a way I can allow a subset of git use in a nicer way without the less nice commands?

Re: Rewriting Bun in Rust

#382

Post by netdur »

ksec wrote: post #292
Philpax wrote: post #5

Without commenting on Bun itself as a project, or the nature of the rewrite, it can't be good for Zig that a naive rewrite away from it fixed memory leaks, improved stability, shrunk binary size by 20%, and improved performance by 5%.

I hope Zig won't do a hostile reply to this blog post. But some thoughts on Zig's future where a lot of these problems could be fixed or migrated by better tooling and compiler checking. But a lot of people have been saying this for sometime, Rust and LLM is a great match. A lot of friction of the language were smoothed out by LLM assisted programming.

Zig and Rust solve different problems, Bun got burned by its indiscipline, and Zig’s response was sadly to flood HN with “how to use Zig” articles

Re: Rewriting Bun in Rust

#383

Post by dbdr »

jackdoe wrote: post #356
Sammi wrote: post #298

Earlier quoted context omitted.

"In economics, the Jevons paradox is said to occur when technological improvements that increase the efficiency of a resource's use lead to a rise, rather than a fall, in total consumption of that resource. Greater efficiency reduces the amount of the resource needed per application, lowering its effective cost; if demand is sufficiently price elastic, this induces demand, frequently resulting in a net increase of to…

the elastic demand will be consumed by ai jevon's paradox just says people will consume more software as software gets cheaper, which is likely true, not that there will be more high paid jobs for programmers. as programmers are not the resource, the program is the resource, programmers were the means of production of said resource. stated differently: in a world where you dont need programmers to make programs, ther…

You are assuming an infinite productivity boost, i.e. that no programmers at all are needed to make programs.

A more realistic scenario is that programmers are still needed in the foreseeable future (for some definition a what a programmer is, even if it's "understands software enough to be able to write good prompts and judge the results"). So the question is how the productivity boost compares to the increase in the amount of software being made.

Re: Rewriting Bun in Rust

#384

Post by xyzsparetimexyz »

Philpax wrote: post #5

Without commenting on Bun itself as a project, or the nature of the rewrite, it can't be good for Zig that a naive rewrite away from it fixed memory leaks, improved stability, shrunk binary size by 20%, and improved performance by 5%.

No, you don't get it. Zig is a language about having _fun_. Not memory safety and all that crap. That's why unused variables are hardcoded as errors!

Re: Rewriting Bun in Rust

#385

Post by flohofwoe »

khuey wrote: post #362
flohofwoe wrote: post #280

Earlier quoted context omitted.

Rust-the-language may be medium-sized. Rust-the-stdlib though? The Rust stdlib has a lot of essential low-level types needed for adding a 'semantic layer' on top of the language so that the language user can exactly 'express intent' (types that arguably should be language features instead). Just look at all those detailed methods needed to make RefCell work, and what does 'into_inner' or 'undo_leak' even mean? https:…

> what's a single concept in C (e.g. "the pointer") easily has a dozen specialized equivalents in Rust That "the pointer" is a single concept in C is the root cause of absurd numbers of bugs over the history of C. The questions of how long the memory a pointer points to lives, what threads it is safe to access from, and how it is allocated and destroyed all still exist in C. Those answers are just implicit rather tha…

In general I agree, but this topic is IMHO exactly what separates the Rust lovers from the Rust haters ;) E.g. how strong is too strong when it comes to type systems. Rust afficionados generally seem to tend towards 'the stronger the better', and accepting the downside of a fairly rigid code base.

I prefer a middle ground between strong and weak typing (but yeah, C is arguably too weakly typed, but the exact sweet spot is different for every programmer).

A reasonably smart C compiler that has visibility on all code in a project could theoretically infer a lot of the same semantic details that must be manually provided in Rust by looking at how the pointer is used in the wider codebase (basically what static analyzers are doing by reconstructing control flows). Of course such an extensive analysis would result in even worse compile times than Rust ;)

Re: Rewriting Bun in Rust

#386

Post by giancarlostoro »

MindSpunk wrote: post #172
giancarlostoro wrote: post #50

Earlier quoted context omitted.

I've done rewrites like this, maybe it wasn't Zig to Rust, but I have been able to rewrite sizable projects, from C# to Rust before. I incorporated a similar strategy, have Claude Opus review the codebase, write a spec, then have Claude implement it, while reviewing the spec, and using the codebase as fallback and gospel over the spec. That said, it's not the entire story here as I said, there was a lot of thought pu…

Curious why you'd move from C# to Rust. C# has you covered mostly for memory safety so I would guess performance or lots of shared memory across threads?

This was purely a hobby project I wanted to test the limits of Claude and see how quickly it could do such a change. It was surprisingly very stable I still found bugs but was able to resolve them within a small time window. For additional context I didnt use Fable as only Opus was available to me.

Re: Rewriting Bun in Rust

#387

Post by randypewick »

didibus wrote: post #80

Article did a decent job of showing discipline and care and human involvement to assert the automated rewrite was done diligently, as best as it can be when using AI for it. I does make me feel a bit more comfortable about it. As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026. Rust gives you that in a performant package, so if you are turned off by GCs…

Rust is C++ like language, with more safety. It makes no sense to say that to get performance one can drop down to C++. As far as I am aware, you can get as fast as C with Rust. Of course, that might mean to compromise on something, some bound checks, some code ergonomics, or something else. You can write ASM in Rust, so it really gets as low level as it gets. And what I find amazing is that, similarity to C++, you can get both low level and high level code in the same language. And this is intrinsic in the language complexity: if you take a simpler language with a less powerful type system (C-class languages), you lose this ability.

Re: Rewriting Bun in Rust

#388

Post by [deleted] »

fragmede wrote: post #112
daishi55 wrote: post #95

Earlier quoted context omitted.

> There’s no way in hell it’s maintainable This is not an assertion you are qualified to make > Go read any analysis of the Claude Code leak for proof You seem to be implying that Claude code is unmaintainable. Yet they appear to be maintaining it just fine. Did I misunderstand your implication?

Claude code is buggy and they don't appear to be maintaining it just fine.

[deleted]

Re: Rewriting Bun in Rust

#389

Post by SwiftyBug »

nvader wrote: post #183
malisper wrote: post #130

Earlier quoted context omitted.

I can confirm a naive rewrite won't make things faster. I've been working on rewriting Postgres in Rust. I rewrote things function by function similar to how Jarred did. Even though the new Rust code mapped closely with the previous C code, it was 8x slower. This was due to myriad of reasons. For example naively converting a C union into a Rust enum can be slower because Rust stores a tag with the enum, while C union…

I hope that you're going to call it PostGrust.

Na, PostPostgres would be much cooler.

Re: Rewriting Bun in Rust

#390

Post by jdkoeck »

daishi55 wrote: post #117
fragmede wrote: post #112

Earlier quoted context omitted.

Claude code is buggy and they don't appear to be maintaining it just fine.

I use it all day every day and haven’t noticed any bugs. And the fact is that they are maintaining it and it is one of the most successful software products of all time and is earning them mountains of cash. By any metric it is a successful product. So obviously whatever they are doing is working.

Last time I used it, it was a a flicker fest. Has it been fixed?
Post reply on HN