This blog post further undermines my trust in Jarred.
He makes it sound like Claude did a fantastic Rust rewrite, and "the work continues."
But when the Rust port merged to main, the state of the code was very, very bad. There were 13,000 instances of `unsafe`, no Miri tests at all, and, sure enough, it exposed UB in safe Rust. https://github.com/oven-sh/bun/issues/30719
Observers could see this coming from a mile away, objected strongly to using AI to RIIR before the code merged. Rather than incorporate feedback and get the code ready for production, Jarred gaslit us all, right here on HN. https://news.ycombinator.com/item?id=48019226
Just 9 days before he merged the Rust rewrite to the main branch, Jarred wrote:
> This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.
It's plausible that Bun's Rust rewrite is now in much better shape than it was in May. But a blog post like this would have been a place to apologize, to accept that it was a very bumpy rollout, to acknowledge that public messaging was extremely poor, and to earn back our trust.
As it stands, I guess I'll have to run my own tests to try to evaluate whether Bun 1.4 is ready for prime time, because I just can't trust Jarred to give us a straight answer.
Pre-release code had bugs that were fixed before the release? Why is that a problem? That's the point of having a testing and release process
It's partly a problem because the narrative is still "rewrote Bun in Rust in 11 days". And they didn't do that, if you consider quality of code. And now people look and see "look what you can do with an LLM in 11 days"
what about new bugs introduced after the rewrite?
Got a reference to something specific? Per the blog post the overall quality, speed and size all improved. And multiple users have corroborated.
Like have you run into a specific bug or seen a regression - that's the cause of your reaction?
> We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely.
God forbid an engineer express uncertainty.
Engineers are pretty jaded about plans expressed by authority, especially when there are obvious pressures opposing those plans. Yearly planning doesn't matter when a reorg will change the trajectory by Q3. Sprint planning doesn't matter when you know a fire will hit before then and you won't be given enough time budget to fix it well enough for that not to happen again next sprint. Project planning doesn't matter when the whole point is masturbatory spreadsheet production before you've actually taken a dive into the hairier details and figured out what's possible and what's necessary. That barely working demo strapped on top of a non-existent backend they swore would never become production? Congratulations, you have two weeks to build the next fake demo on top of it, but the base has to actually work now.
Maybe Jared just broadcasted uncertainty and was wrong, but given his position he's not being given the normal grace you might extend to an engineer you trust.
Uncertainty is one thing, but a high chance means it’s 51% or higher to me.
Based on that, the bun rewrite messaging was fairly misleading.
That was their estimate at the time, based off the information they had. You can't ask more of someone than that.
Either they estimated poorly, or it ended up the lesser portion of their estimate after all. After all, unless the estimate is 100%, there's always a chance it'll fall into the other portion.
To understand your error, consider that in the month leading up to the 2016 US presidential election, the widely-accepted probabilities were between 70% (Five-Thirty-Eight) and 90% (Reuters) in favour of Clinton.
> But when the Rust port merged to main, the state of the code was very, very bad. There were 13,000 instances of `unsafe`, no Miri tests at all, and, sure enough, it exposed UB in safe Rust.
I mean yeah, that's what this whole post is about. It's about the process of going from that original state to something that's now shipping in production.