Even if you do, you still will. Just less often.
> I actually have no idea how big teams work on large C++ codebases... You can change one part of the code, and it will introduce bugs in the whole project because of how the memory is handled
Part of it is lots of tests, sanitizers, assertions, etc.
Part of it is keeping things modular and avoiding spooky action at a distance to the extent possible.
Part of it is unavoidable, and that's why people are moving to safer languages.
This, so much this!
The trade-off between compile-time and run-time checking depends in large part on the time needed to address the issue. It's not really black and white. People just don't want to wait forever for static verification - I think that's kind of why clang-static-analyzer isn't used as much as clang-tidy.
They choose a memory management strategy and stick to it. Of course, the problem, relative to something like rust, is the compiler doesn't enforce it. You can use linting tools and/or reviews.
> Usually, you need to have a good idea of how the whole thing works. You can change one part of the code, and it will introduce bugs in the whole project
That's not a problem with C++ specifically. That's a problem with organization. It's probably best know as the "Big Ball of Mud" architecture[1]. Rust has no particular defense against it, nor other languages that I am familiar with. If you don't see it as much with rust it's only because it takes time to develop. (counter-intuitively, it's an impressively successful architecture -- so many long-lived projects use it).
Why would it do that?
There are still logical holes in the borrow checker, but they're mostly irrelevant.
Well yeah, you don't. Most people who comment on these sorts of threads don't, which obviously colors their bias in favor of the solution they do understand.
For Rust, you just have to fight the compiler. This is especially useful when you have people on your team with some experience who also want to contribute, but you don't want to constantly point them in the right direction.
I actually have no idea how big teams work on large C++ codebases. Usually, you need to have a good idea of how the whole thing works. You can change one part of the code, and it will introduce bugs in the whole project because of how the memory is handled. Isolated changes are hard. And historically, a lot of C++ codebases lack good test coverage.