6 ms·

LLM-assisted software engineering seems to be very efficient if you have a deterministic target. (bun rewrite from zig to Rust, 100% Node.js compatibility, pnpm

by pas 1mo ago

LLM-assisted software engineering seems to be very efficient if you have a deterministic target. (bun rewrite from zig to Rust, 100% Node.js compatibility, pnpm compatibility -- https://github.com/oven-sh/bun/pull/38333 https://github.com/oven-sh/bun/pull/38333)

croon 1mo ago
My pushback on that would be that all of the "engineering" concering a rewrite was already done the first time around. It's a glorified translation. I do agree that the port would've taken a lot longer without LLMs though.
Sharlin 1mo ago
And how long will it take to rewrite the Rust rewrite to idiomatic safe Rust?
QwenGlazer9000 1mo ago
Problem with that is that it's not proper rust code, it's some kind of franken zig style rust port. The actual hard part is getting it into idiomatic, safe rust, and I don't believe the LLM port makes the full transition any easier than doing things the old fashioned way: a dual lang code base like Linux.
- dist-epoch 1mo ago
  And compiler generated assembly code is ugly and spaghetti, unlike beautiful hand-crafted human written assembly code, the kind you see in ffmpeg codecs, ... Doesn't matter.
  - QwenGlazer9000 1mo ago
    It does matter, because that's the entire point of the language. You know, memory safety? The vibe coded rust port did not get them any closer to full compiler verified memory safety. They still need to go file by file, bit by bit, and make it memory safe, at which point, why not just do that from zig.
    - pas 1mo ago
      > at which point, why not just do that from zig. because for the same effort you get a better result if you can and do use a better tool?
      - QwenGlazer9000 1mo ago
        I didn't say don't use LLMs. In fact, I'm quite certain they could help quite a bit. But I don't think they did it in a way that actually provided a meaningful gain. My point is that the state of the codebase right after the code is just a worse version of the original zig code with few of the rust advantages. Going from that Frankenstein rust code to actual memory safe rust is a similar leap to going from zig.
- pas 1mo ago
  > I don't believe the LLM port makes the full transition any easier than doing things the old fashioned way: a dual lang code base like Linux ... how so? let's say Linus opens a branch, rust-temp, and in 2 weeks pushes ~15 million lines of code deleting most of the old C code. and then it gets merged in a few weeks. and then there's still a few months of the "merge window" and RC process. and each day folks report bugs, and automatic fuzzers make sure that both versions "behave the same". I was pretty skeptical (still am), but what the Bun team did is pretty great so far. https://bun.com/blog/bun-in-rust https://bun.com/blog/bun-in-rust details the process, we see the results (Node.js compat [0], more than 3 thousand of issues fixed since since 1.3 [1], more than 900 issues fixed in ~24 hours [2], and it's live/in-prod [3]) > 50 dynamic workflows in Claude Code run continuously over the course of 11 days. so let's say 500 workflows could do something similar for the kernel. the reported cost is 165K USD, so let's say this would cost 1.65M USD, plus CI costs [4] (which is ~200K/year for bun, so let's say it's 2M USD for the kernel) How much the world is spending on kernel bug bounties and various security programs each year? (rough estimate says that just the visible kernel testing programs cost at least 15-30M / year) The bar is not perfect. The bar is something better. [0] https://xcancel.com/bunjavascript/status/2087436767054213517#m https://xcancel.com/bunjavascript/status/2087436767054213517... [1] https://xcancel.com/bunjavascript/status/2082298681223680002#m https://xcancel.com/bunjavascript/status/2082298681223680002... [2] https://xcancel.com/bunjavascript/status/2080882189663907859#m https://xcancel.com/bunjavascript/status/2080882189663907859... [3] https://news.ycombinator.com/item?id=48966569 https://news.ycombinator.com/item?id=48966569 [4] https://news.ycombinator.com/item?id=49070494 https://news.ycombinator.com/item?id=49070494
  - jacquesm 1mo ago
    Great example. There is no way I would run that in production anywhere. Long term stability is the thing that matters, such a move would be immensely threatening to long term stability.
    - pas 1mo ago
      the neat part is that you don't have to, millions will do it for you! the point is that it's a quite obvious opportunity that was just some pipedream years ago. by the time v8.0 comes around we'll have more data on the bun rewrite. also we'll see how LLMs will affect the productivity of kernel developers, and the overall stability/maintainability.

by pas 1mo ago

croon 1mo ago

My pushback on that would be that all of the "engineering" concering a rewrite was already done the first time around. It's a glorified translation. I do agree that the port would've taken a lot longer without LLMs though.

Sharlin 1mo ago

And how long will it take to rewrite the Rust rewrite to idiomatic safe Rust?

QwenGlazer9000 1mo ago

Problem with that is that it's not proper rust code, it's some kind of franken zig style rust port. The actual hard part is getting it into idiomatic, safe rust, and I don't believe the LLM port makes the full transition any easier than doing things the old fashioned way: a dual lang code base like Linux.

dist-epoch 1mo ago
And compiler generated assembly code is ugly and spaghetti, unlike beautiful hand-crafted human written assembly code, the kind you see in ffmpeg codecs, ... Doesn't matter.
- QwenGlazer9000 1mo ago
  It does matter, because that's the entire point of the language. You know, memory safety? The vibe coded rust port did not get them any closer to full compiler verified memory safety. They still need to go file by file, bit by bit, and make it memory safe, at which point, why not just do that from zig.
  - pas 1mo ago
    > at which point, why not just do that from zig. because for the same effort you get a better result if you can and do use a better tool?
    - QwenGlazer9000 1mo ago
      I didn't say don't use LLMs. In fact, I'm quite certain they could help quite a bit. But I don't think they did it in a way that actually provided a meaningful gain. My point is that the state of the codebase right after the code is just a worse version of the original zig code with few of the rust advantages. Going from that Frankenstein rust code to actual memory safe rust is a similar leap to going from zig.
pas 1mo ago
> I don't believe the LLM port makes the full transition any easier than doing things the old fashioned way: a dual lang code base like Linux ... how so? let's say Linus opens a branch, rust-temp, and in 2 weeks pushes ~15 million lines of code deleting most of the old C code. and then it gets merged in a few weeks. and then there's still a few months of the "merge window" and RC process. and each day folks report bugs, and automatic fuzzers make sure that both versions "behave the same". I was pretty skeptical (still am), but what the Bun team did is pretty great so far. https://bun.com/blog/bun-in-rust https://bun.com/blog/bun-in-rust details the process, we see the results (Node.js compat [0], more than 3 thousand of issues fixed since since 1.3 [1], more than 900 issues fixed in ~24 hours [2], and it's live/in-prod [3]) > 50 dynamic workflows in Claude Code run continuously over the course of 11 days. so let's say 500 workflows could do something similar for the kernel. the reported cost is 165K USD, so let's say this would cost 1.65M USD, plus CI costs [4] (which is ~200K/year for bun, so let's say it's 2M USD for the kernel) How much the world is spending on kernel bug bounties and various security programs each year? (rough estimate says that just the visible kernel testing programs cost at least 15-30M / year) The bar is not perfect. The bar is something better. [0] https://xcancel.com/bunjavascript/status/2087436767054213517#m https://xcancel.com/bunjavascript/status/2087436767054213517... [1] https://xcancel.com/bunjavascript/status/2082298681223680002#m https://xcancel.com/bunjavascript/status/2082298681223680002... [2] https://xcancel.com/bunjavascript/status/2080882189663907859#m https://xcancel.com/bunjavascript/status/2080882189663907859... [3] https://news.ycombinator.com/item?id=48966569 https://news.ycombinator.com/item?id=48966569 [4] https://news.ycombinator.com/item?id=49070494 https://news.ycombinator.com/item?id=49070494
- jacquesm 1mo ago
  Great example. There is no way I would run that in production anywhere. Long term stability is the thing that matters, such a move would be immensely threatening to long term stability.
  - pas 1mo ago
    the neat part is that you don't have to, millions will do it for you! the point is that it's a quite obvious opportunity that was just some pipedream years ago. by the time v8.0 comes around we'll have more data on the bun rewrite. also we'll see how LLMs will affect the productivity of kernel developers, and the overall stability/maintainability.