[hmfrh]

> So ultimately, the borrow checker doesn’t seem worth it if you actually think about the cognitive overhead and headaches it brings.

You quite literally also have to "borrow check" C/C++ in order to have a well formed program, just without any compiler assistance.

[cyber_kinetist]

For heap-allocated objects, there is a way to do borrow checks at runtime if you want (there's something called constraint references, explained in https://verdagon.dev/blog/raii-next-steps.)

For structs that I do not want to heap-allocate, they're usually POD types and in arrays (which you can bound check), so there's not much to think about borrowing. The more concerning issue I usually have is about about initializing the values correctly (which usually Rust doesn't help, when reasoning about performance-sensitive code).

[estebank]

> For structs that I do not want to heap-allocate, they're usually POD types and in arrays (which you can bound check), so there's not much to think about borrowing.

Both situations which also apply to Rust. Whenever the borrow checker complains you can do exactly the same thing.

> The more concerning issue I usually have is about about initializing the values correctly (which usually Rust doesn't help, when reasoning about performance-sensitive code).

You can use a type-state machine, where the only way to construct the final value is by calling all of the appropriate methods that change the type parameters on the Self type. When that gets compiled it ends up as either a single memcopy of values, or you can make the Self type hold a MaybeUninit value to make the partial construction with no copy at the end possible. I actually implemented that for fun and as it turns out already existing crates that held every field in an Option and then built the final value from those ended up being faster. C'est la vie.