This comment inspired me to take a look at the trend of "unsafe" in the Bun code over time since the rewrite PR first landed - here are the commits where that number changed by at least 10:
The original code was one giant unsafe block with almost no tangible way to find or debug all the subtle memory bugs and leaks they had.
Now it's smaller, faster and has fewer bugs. Also its every potential memory issue is neatly annotated by an unsafe block so you can go and refactor them out one by one with confidence.
All this seems like a pretty huge improvement to me. Why is this an abomination in your eyes?
Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them.
> every potential memory issue is neatly annotated by an unsafe block
"Potential memory issue" can originate in unsafe blocks and safe code that are able to alternate the input condition of these unsafe blocks. Guess what? That still counts towards 100% in this code base, hence the abomination remark.
> refactor them out one by one
Not as easy as it sounds. They are like threads in a yarn ball, if there are one or two ends visible it's easier to sort them out. The actual situation is more like we have tens of thousands of ends (all the raw pointer code that comes with every shared object), to fix them it's basically a requirement to unwind the whole thing (rewrite all the callees and reorder the data flow as needed, redesigning all the APIs during that).
It's too early to declare it as anything remotely close to a win, optimistically saying.
For someone who is not a rust dev, would you mind giving me an example of this:
"Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them."
> Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them.
I'm not sure I'm following what you're saying here. In the rewrite blog post it has been stated that the Rust port landed in a place where it passes 100% of the existing test suite and does so without some of the known memory leaks of the Zig version that they were aware of and didn't know how to address.
Sure, there's no guarantee that the port didn't introduce new bugs and most likely it did, but the 1.4 version has not been released yet, so I don't think a direct comparison of a long-time "stable" version and the just-landed full rewrite is meaningfully helpful.
> "Potential memory issue" can originate in unsafe blocks and safe code that are able to alternate the input condition of these unsafe blocks. Guess what? That still counts towards 100% in this code base, hence the abomination remark.
But that just means that once you get rid of the unsafe block, you're pretty much guaranteed by the Rust compiler to be memory-safe. This means that all your potential memory landmines are annotated in the code and once you disarm them all, you're memory-safe.
I don't understand how what you're saying contradicts any of my statements.
> Not as easy as it sounds. They are like threads in a yarn ball, if there are one or two ends visible it's easier to sort them out.
Still easier than the Zig version, where all the same things you've mentioned apply, but also there's no visible indication of progress and issues are unmarked and could be pretty much anywhere.
> It's too early to declare it as anything remotely close to a win, optimistically saying.
Based on the rewrite blog post it's pretty clear that the Rust version is outperforming the Zig version by pretty much every measurable metric at this point.
I think the backlash is mostly focused on the ideological opposition to fully AI-authored 1MLOC+ PR approach they took.
who claimed that? Are you suggesting that the rewrite did not introduce any new bugs? The correct answer is, by the way, that no one knows since it's millions of lines of code no one has properly read.
> smaller, faster
I thought this has already been debunked. You could just write better zig and make it smaller, faster (and have fewer bugs!)
This comment inspired me to take a look at the trend of "unsafe" in the Bun code over time since the rewrite PR first landed - here are the commits where that number changed by at least 10:
So not as much cleanup as I had expected!
ChatGPT written script for counting here: https://gist.github.com/simonw/b1015bcadcedd1a781cedb7af9cbb...
The original code was one giant unsafe block with almost no tangible way to find or debug all the subtle memory bugs and leaks they had.
Now it's smaller, faster and has fewer bugs. Also its every potential memory issue is neatly annotated by an unsafe block so you can go and refactor them out one by one with confidence.
All this seems like a pretty huge improvement to me. Why is this an abomination in your eyes?
> The original code was one giant unsafe block
True.
> has fewer bugs
Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them.
> every potential memory issue is neatly annotated by an unsafe block
"Potential memory issue" can originate in unsafe blocks and safe code that are able to alternate the input condition of these unsafe blocks. Guess what? That still counts towards 100% in this code base, hence the abomination remark.
> refactor them out one by one
Not as easy as it sounds. They are like threads in a yarn ball, if there are one or two ends visible it's easier to sort them out. The actual situation is more like we have tens of thousands of ends (all the raw pointer code that comes with every shared object), to fix them it's basically a requirement to unwind the whole thing (rewrite all the callees and reorder the data flow as needed, redesigning all the APIs during that).
It's too early to declare it as anything remotely close to a win, optimistically saying.
For someone who is not a rust dev, would you mind giving me an example of this: "Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them."
9 replies →
> Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them.
I'm not sure I'm following what you're saying here. In the rewrite blog post it has been stated that the Rust port landed in a place where it passes 100% of the existing test suite and does so without some of the known memory leaks of the Zig version that they were aware of and didn't know how to address.
Sure, there's no guarantee that the port didn't introduce new bugs and most likely it did, but the 1.4 version has not been released yet, so I don't think a direct comparison of a long-time "stable" version and the just-landed full rewrite is meaningfully helpful.
> "Potential memory issue" can originate in unsafe blocks and safe code that are able to alternate the input condition of these unsafe blocks. Guess what? That still counts towards 100% in this code base, hence the abomination remark.
But that just means that once you get rid of the unsafe block, you're pretty much guaranteed by the Rust compiler to be memory-safe. This means that all your potential memory landmines are annotated in the code and once you disarm them all, you're memory-safe.
I don't understand how what you're saying contradicts any of my statements.
> Not as easy as it sounds. They are like threads in a yarn ball, if there are one or two ends visible it's easier to sort them out.
Still easier than the Zig version, where all the same things you've mentioned apply, but also there's no visible indication of progress and issues are unmarked and could be pretty much anywhere.
> It's too early to declare it as anything remotely close to a win, optimistically saying.
Based on the rewrite blog post it's pretty clear that the Rust version is outperforming the Zig version by pretty much every measurable metric at this point.
I think the backlash is mostly focused on the ideological opposition to fully AI-authored 1MLOC+ PR approach they took.
1 reply →
> has fewer bugs
who claimed that? Are you suggesting that the rewrite did not introduce any new bugs? The correct answer is, by the way, that no one knows since it's millions of lines of code no one has properly read.
> smaller, faster
I thought this has already been debunked. You could just write better zig and make it smaller, faster (and have fewer bugs!)