I'm not an expert in this field, but it's my understanding that this is often the case for C programs executing nowadays. The AMD64 architecture even has the NX bit. There are some other ways that this can be enabled too.

But surprisingly, this doesn't solve all code execution security problems from buffer overflows. Sometimes exploiters can find non-executable memory to change that allows them to change the program behavior to do what they want, such as changing the command string that gets passed to a normal execve call later in the program.

But even if you solve the security issues, buffer overflows are still a huge headache. A one byte buffer overflow can cause your program to crash an hour later, with almost no hope of figuring out why it happened. A developer can easily spend weeks tracking down a single buffer overflow crash.

> Sometimes exploiters can find non-executable memory to change that allows them to change the program behavior to do what they want, such as changing the command string that gets passed to a normal execve call later in the program.

Changing function pointers or the return value on the stack are the normal things to do. In particular if you corrupt the stack you can simply return into system() with whatever arguments you want.

>A one byte buffer overflow can cause your program to crash an hour later, with almost no hope of figuring out why it happened.

I don't know about rust, but you can have an ArrayOutOfBoundsException in Java, and equivalent in Go and other safe languages

Because that isn't enough:

https://en.wikipedia.org/wiki/Return-oriented_programming

This wouldn't protect from bugs where you can maliciously trick a program from reading from other places in memory so it will leak passwords, keys etc. Think heartbleed

That is done already in many cases.

Note that doing that doesn't fix all of the problems that out of bounds array writes can cause though.