Comment by reliabilityguy
6 hours ago
Many repeat the point of “$165k is cheaper than team of multiple engineers working on the rewrite for a year”, which I think is flawed — the team of engineers would have produced idiomatic rust, and it would take probably 100k+ of tokens more to make the bun in rust idiomatic rust.
They also would have produced a team of engineers that knows the Rust codebase.
"Knowing the codebase" seems like an antithetical philosophy to LLM driven engineering orgs.
This is assuming your engineers don't leave for higher-paying roles elsewhere. The market might be cold generally but for engineers working at these frontier AI companies it's red-hot.
And most executives are figuring this into their calculus right now because they were burned badly during COVID. Meta, Google, etc were loose with hiring and engineers flocked from their lower-paying companies in droves. The brain drain was real.
One public company I was at lost nearly 2/3rds of their engineers and mostly to Meta (granted, they had other problems but it was mostly about money -- the offers were excessive). Then market conditions forced them to freeze hiring and they've had a slow exodus of senior talent since as the firefighting has become constant.
AI adoption has only accelerated problems for them.
We've taken this "only two years and then leave" philosophy to an extreme and now companies are totally justified in not investing in their engineers anymore.
The job-hopping followed from companies not investing in their engineers, not the other way around. It was billed as the only way to get a promotion (which usually would come every 1-2 years).
3 replies →
I feel your estimate of tokens is a few orders of magnitude off, it’s on the low side.
I use more (albeit cached) when centering a div.
I think they missed a $ sign, i.e. they meant $100k of tokens
This is where we've come to where people proudly proclaim using an AI to do what is a single line of CSS.
"centering div" is a classic problem (/trauma/meme) that sounds trivial but had no universal solution (until 2017?).
1 reply →
100k tokens is your pre-prompt and your CLAUDE.md as well as a few files from your root.
What a great joke.
I will have to steal it for an upcoming AI tools meeting I have at work.
Also, pretty clever as centering a div w/ CSS has been notoriously difficult to achieve.
Would they have, in a year? The general plan of attack would likely still be the same: rewrite it in rust while keeping the structure as similar as possible, no matter how unidiomatic, then adjusting the design to make it more idiomatic to rust. Doing both at once is much harder.
IMO a team of engineers (presuming this is pre-AI) would have improved the existing Zig codebase, rather than spent time and money on a Rust port in the first place. In fact, I still think most teams of engineers would choose to improve what they have even now, circa AI.
I doubt file by file rewriting takes as much work as rewriting and refactoring the code - especially at this scale.
Yes this is a typical case of showing results fast. I wonder what the cost for the remaining 10℅ of debugging and fixing all the bloat will be. Not so cheap I am guessing
> produced idiomatic rust
I keep seeing this. What is "un-idiomatic" rust?
Rust contains the ability to do everything that C can, if you use `unsafe`. And a file-by-file rewrite in Rust from another language usually involves keeping the ABI and API between files very C-like (and unsafe). In practice this means that the result of a first pass this way has all the memory safety of C code, but with worse readability because Rust makes unsafe things less ergonomic.
To actually get the safety benefits of Rust in a real way you have to rework those files to not treat eachother as C code. This is the interesting and the difficult part of a rewrite in Rust, and one that an unsupervised LLM rewrite is probably not even going to attempt.
I don't think this latter stage has actually happened with Bun's codebase. The result of the Rust rewrite in Bun's case is actually less safe than the Zig it is replacing, especially because (I am told) a lot of the new Rust code is unsound (introducing UB).
> To actually get the safety benefits of Rust in a real way you have to rework those files to not treat eachother as C code. This is the interesting and the difficult part of a rewrite in Rust, and one that an unsupervised LLM rewrite is probably not even going to attempt.
You can use deterministic linting for `unsafe` usage, have agents target `unsafe`, etc. It's pretty easy. You can even run `miri` against the code and give that as a tool for LLM feedback. I've done this all before and it works fine.
> The result of the Rust rewrite in Bun's case is actually less safe than the Zig it is replacing, especially because (I am told) a lot of the new Rust code is unsound (introducing UB).
I'm unconvinced that this is true. How could you tell? You only know about the rust bugs because rust makes them grep'able/ trivial to verify, there's no way of knowing which bugs existed in zig that didn't translate. Regardless, the problem is now trivial to understand in Rust and start to target.
> one that an unsupervised LLM rewrite is probably not even going to attempt.
Why not? A complete test suite exists, so it just boils down to "reimplement this code to reduce the number of 'unsafe' references, while keeping the tests passing" (the last part isn't even needed since Claude loves to run tests and linters anyway).
2 replies →
Presumably lots of stuff wrapped in 'unsafe'. I'm not a rust guy or a rust fan, and the last time I wrote something with Rust was like 7 years ago, but to my memory, because of how Rust manages mutability there are many access patterns that are Rust-specific; idiomatic Rust is going to use this patterns but they would be unlikely to show up in a language with a different type system / borrow checker / etc. etc.
So "unidiomatic" rust means, 'don't use these parts of the language even though they're first-class citizens?'
How odd. Lot of mental gymnastics going on there.
6 replies →
[dead]