I probably have forgotten more programming languages than you can list, and if there are constants in programming, then a) while compilers get better at catching bugs, they never got over the basics, and b) a good programmer will alyways be better at preventing and catching bugs than a compiler.

I agree with this

Once you have aquired a good mindset about disciplined programming, those buglets a compiler (or even code review systems) can find usually don't happen.

I also agree with this.

I would like to put a lot of emphasis in the usually. It doesn't mean that they don't happen, no human being makes no mistakes. Rust simply gives people a little more peace of mind knowing that unless they use unsafe they're probably fine in terms of memory issues.

As a side note, there was this once I was making an ecs engine in rust, and kept fighting the compiler on this issue. Specifically, the game engine bevy uses Query in the World to retrieve information about the game state, and I wanted to do the same. For instance, in the following function (or something similar, I honestly don't remember all that well):

fn getplayer(player: Query<Player>) {}

Would get player from the world and assign it to player (more or less). However rust was adamant in not letting me do this. After some thinking I finally realized why

fn getplayer(player: Query<Player>, player_too: Query<Player>) {}

Would give two mutable references to the same Player in the same function, which can be very easily mishandled, and thus is not allowed in rust.

I don't know about the MISRA standard, but I don't think that using it would have changed the way I coded my inherently flawed approach. This is a small example, one that didn't even matter that much in the grand scheme of things and could be even hard to understand why it's bad without knowing rust, but it is the one that came to mind. I think that if I had more experience I would he able to give you one that actually had security implications.

I'm no seasoned programmer, however