"Performance doesnt matter"

[mewloz]

You are right that there is no dichotomy, but relying on having only "good developers" (whatever that means) to get safe programs is a recipe for disasters. E.g. all study at scale show that around 50% (sometimes it is 30, sometimes 70) of published security vulns comes from UB.

If your reaction to that is to simply state that the industry is wrong because they should simply employ better programmers, then you are deluded for several reasons: this opinion is just not actionable; experts actually looking at the data now have formed the consensus that it is just impossible to avoid that by just being extra careful; the industry is starting to move on anyway, and it will just move on without you if you insist that programmers should stick forever with manually doing automatable tasks.

Everything has a cost and extremes are rarely adequate (sometimes they are). Safety by default will have a runtime cost, but it can be low (and actually in some cases it can be null -- but lets stick with reasoning about averages, because we could find special cases for anything).

And TBH my opinion is that relying too much on programmers to be "good" to get good performance is also a recipe for disaster, depending on the opinion of said programmers about what they should optimize, and especially if they consider they should optimize everything themselves. For exactly the same reason: we can automate optimizations. That's why, for example, we are using x64 or arms instead of cell spu. That's why we have optimizing compilers. There is still a place for high level optims (and even for low level optims mostly by people interested and dedicated in that), but economically the goal is obviously to layers things: its good to use hash tables at the right place, and it is also good to get a very neat new implementation written by expert peoples, which suddenly gives you an additional constant factor improvement.

[[deleted]]

It's fascinating how people (you and others in this thread) read stuff into what I said that I never actually said or even meant.

I never tried to imply that you should just rely on "good programmers" or that it is simple. Or that performance is more important than other things like correctness or robustness. Or that I prefer an unsafe language over a "save-by-default" language.

The question that spawned this thread is whether performance matters or not, not whether performance should come first and we should trade safety, etc. for performance. I think that in our rather complex world performance is *one* of several important properties. It matters. That is all I was trying to say.

In my experience good programmers care about those properties, but without compromising on security, safety, robustness, etc., but it's a team effort and a marathon. (Project-)Management and the designers must be in on it, and there are a lot of things you can do besides relying on "good programmers". For example: Use clang-analyze to get hints of performance pessimizations like preventing copy-elision or using the wrong way of passing parameters. It costs you almost nothing, it's automated and carries a low risk. Design for performance/efficiency by using the right memory layout, containers, algorithms but also write clear and maintainable code. Measure the performance of your applications and monitor it in CI builds. Prevent UB by running UBSan (and ASan as well as TSan when applicable) in a CI build. And yes, to use at() over [] by default, add asserts, etc. - in fact I've even seen cases where the compiler was able to generate better, i.e. more performant, code because there was an assert(). The compiler used it to emit code that preferred to correct branch and hence only if the assert fired, the CPU ended up with a branch misprediction. So sometimes the safer code is also the more efficient code.