That's the thing. You still have to think about lifetimes when you refactor C++ code too. I have accidentally introduced segfaults refactoring my own C++ code, that is for certain.
You still have to do all the hard work thinking about lifetimes even in C++, things like whether lifetime A will surpass lifetime B and all that jazz. It's just not spelled out.
> That's the thing. You still have to think about lifetimes when you refactor C++ code too. I have accidentally introduced segfaults refactoring my own C++ code, that is for certain
As long as you work a bit defensive and do not use references or raw pointers and use smart pointers and values (span and string_view are NOT values, they have reference semantics), things should be ok lifetime-wise.
It is just that we just want to go, sometimes, a tiny bit faster and fall into the temptation of returning a reference or similar and we mess it up when refactoring. But if you take into account the 80/20 rule, then sticking to safe practices should be the default most of the time and leave a pointer or a reference for an inner loop or something performance-critical in a very controlled environment is the wise choice.
In my experience, sticking to these practices make things work very well in practice. I rarely see a segfault in my code when coding C++. I also use `.at()` systematically, btw. And I am very conservative when using `string_view` and `span`.
Since it does not have exceptions, same for propagating Result type up and down. Both go viral. The compiler is strict.
Of course you have to think about lifetimes in C++ but it is more flexible.
That said, Rust pattern matching and traits are nice.
Rust is stricter and the learning curve is steeper overall IMHO.
I really think a borrow checker is not the way to go for safety. Hylo language model is what I would choose first above everything else.