That's true of literally all compile time validation.

No I'm not saying I have an issue with compile time validation. Far from it.

My point is that the borrow checker is explicitly meant to protect against data races and such. There are situations where I write code I can prove does not violate any hazards but Rust's "validation" is overly-zealous.

Which ones do you run into most often?

But its more true of some than others.

Yes, some valid code won't pass the borrow checker. But at the same time, far more invalid code doesn't pass it. Personally I see it as a tool to help me reduce possible runtime errors, and instead have them as compile time errors. This does mean that I often need to design my program around it, but that's try of basically every other language.

The few times I do have an issue I'm usually writing FFI code to interact with C, and I try to minimise that code as much as possible.

And of course in Rust, if you Try you might get an Ok Result, or you may just return in Err.

It's often a good exercise to craft your program to the language you're targetting, to take advantage of it's strengths or embrace it's traditions.

There are probably assumptions/invariants built into how rustc generates LLVM IR that you will have to guarantee are met if borrowck is disabled.

Do you really want that?