I don't. I think compile time static analysis is great. Upthread you said this:
> there's no reason why the borrow checker must be in the compiler proper.
On a technical front, I completely agree. But there's an ecosystem benefit to having the borrow checker as part of the compiler. If the borrow checker wasn't in the compiler proper, lots of people would "accidentally forget" to run it. As a result, lots of libraries would end up on crates.io which fail the borrow checker's checks. And that would be a knock on disaster for the ecosystem.
But yes, there's nothing stopping you writing a rust compiler without a borrow checker. It wouldn't change the resulting binaries at all.
> lots of people would "accidentally forget" to run it
yeah, like how the sel4 guys accidentally forget to run their static analysis all the time.
You put a badge on CI. If you "forget to run" the static analysis, then people get on you for not running it. Or people get on you if you don't have the badge. Just like how people get on people for not writing programs in rust.
Q: If we can get men on the moon, why is my lawnmower such a piece of junk?
A: The engineers who got us in to space didn’t design your lawnmower.
The SeL4 team won’t forget to run their static analysis checks. But most people aren’t at their level. Most people just want to get on with it. The borrow checker is a pain in the neck to learn - and if it were optional, you better believe lots of people would avoid it forever. I may well have been in that camp too - I found it really hard to get my head around it!
If you want a modern C-like language without rust’s borrow checker, Zig or Odin is probably a better bet. They’re both fine languages.
> Just like how people get on people for not writing programs in rust.
your argument doesn't hold water, because you are appealing to the existence of a schroedinger's programmer that simultaneously would use rust but also wouldn't turn on a borrow checker if it existed in another language.
My point is the fact that people use Rust means that people do care. And those people will run static analysis checks (as long those static analysis checks aren't the shitty or overly difficult to run), and they will notice that your library isn't checked. Or, better yet, they will integrate it into their project, run the checker on their project, find the problem in the lazy person's dependency and PR a fix or fork it if the maintainer is an asshole.
Here's the thing. Rust is currently "the only game in town" for spatiotemporal memory safety and that is sucking the air out of the atmosphere, because no one wants to invest time into trying other ideas. And that's a shame, because everyone makes assumptions that Rust must be the only way to do spatiotemporal safety (cough cough Ada/Spark). And it gives cover for people to claim things that are presumptuous and totally untested like our schroedinger's programmer here.
Rust has a lot lot lot of shitty things in it, like RAII, and proc macros, and pushing you into some incredibly complicated (and privileged) templated types that are doing some things under the hood (remember when rust switched from jemalloc to malloc?), and Rust hasn't ever gotten to keyword generics yet. Those of us who don't want that kind of BS in our language have to constantly be accused of not caring about memory safety which is hardly the truth.
> your argument doesn't hold water, because you are appealing to the existence of a schroedinger's programmer that simultaneously would use rust but also wouldn't turn on a borrow checker if it existed in another language.
I'm appealing to the existence of people who would like rust very much, but find the borrow checker to be cumbersome / annoying / difficult. I suspect a lot of people would fall into this camp. Including a lot of people who admire Zig, Jai, Odin, dmd. And probably a lot of C++ developers.
In my opinion, most of the best parts of rust have nothing to do with the borrow checker. For example, sum types, the rust standard library, cargo & crates.io, traits, Result / Option, editions, rust's unit testing, etc.
If someone released a borrow checker for zig, would it get 100% adoption? No way. Especially if it was hard to learn, required adding unfamiliar "lifetime annotations" throughout your code and sometimes required you to refactor functions that you know are correct anyway.
> Here's the thing. Rust is currently "the only game in town" for spatiotemporal memory safety and that is sucking the air out of the atmosphere, because no one wants to invest time into trying other ideas. [...] Those of us who don't want that kind of BS in our language have to constantly be accused of not caring about memory safety which is hardly the truth.
I think we've found agreement. I've been saying this for years - Rust is humanity's first serious attempt at a programming language like this. Its like the first iPad. I think there's lots of ways a rust successor could learn from rust's mistakes and make a better language. I'm really looking forward to what a borrow checker might look like a few more languages down the line.
