> Yes, and security has a large performance impact.
Not necessarily. The linked blog talks about SPARK which is about running your code through theorem provers to mathematically formally verify that your code does the correct thing _in all instances_.
Once you have passed this level of verification - you can disable assertions and checks in the release version of the application (whilst of course - having the option of keeping them enabled in development releases).
>Just look at the performance costs of bounds-checking array access in C++ code.
If your compiler can prove you dont need bounds-checking it will remove the check and the performance would be the same. Hence, if your program has been proven to have no runtime errors you dont need them.
> Wouldn’t the performance costs of bounds checking on arrays be the same if the computer was doing it or if your code was doing it?
It depends. The C programmer can choose to do the bounds checking in a for loop by just checking once before the loop begins, or once per iteration even if an array is accessed multiple times in the loop, or the safe language might have more overhead than a simple if statement in the C code. This can, of course, go the opposite direction (the safe language has verified the loop bounds, but the C programmer is checking before every array access). It's a battle between the C programmer and the designer and/or implementer of the safe language.
One of the reasons I like C is it gives you more control. This can be a good or a bad thing. This can lead to some really performant code you couldn't do in most languages or it can lead to some gnarly security problems. Maybe both in the same spot of code.
I use C to write mostly pet projects at home. I use it at work without having a choice in the matter.
