It's more funnier that although language is full of traps, in practice it works quite well. I don't think any C developer(or let's say %95) knows all the rules mentioned in the article, yet we are still one piece.

Does anybody know any paper for bugs per lines of code for different languages or something similar?

C/C++ developers not knowing the rules does bite them. For example, it made the 32-bit/64-bit transition much more painful. See https://www.viva64.com/en/a/0004/ ; https://www.viva64.com/en/a/0065/

But! And that's important -- it allows for great performance, so you can make ten/hundred times more mistakes per second than in other, "safer" languages.

> it allows for great performance, so you can make ten/hundred times more mistakes per second than in other, "safer" languages.

This is false. For a long time C performance used to be inferior to Fortran, which is arguably safer than C. It's hilarious that the strict aliasing and `restrict` keyword was born out of making C on par with Fortran and UB became a major issue to C programmers as a result!

Yes, that's why C has undefined behavior. Absolutely

Nowadays, it doesn't provide any performance gain. I didn't see those days but maybe it was important for performance back in 70s/80s/90s even it was risky? e.g null terminated string was chosen due to low space overhead.

It depends on what you are doing. For some kinds of programs, C/C++ are going to be much faster than most "modern" languages.

I didn't mean C is not fast or not faster than other languages. It's still the fastest one I believe.

What I meant is undefined behaviors allow compilers to optimize in a way that would not be possible otherwise. So, it might be a deliberate decision back then, to leverage performance. I don't know, just an idea.

It used to be "folk knowledge" that only Fortran and hand-crafted ASM were faster. Not sure if that's still (or ever was) true.

I guess it was maybe true one time.

http://www.catb.org/jargon/html/story-of-mel.html

I agree but I didn't consider these while saying C is the fastest. These are not "general purpose", like you don't write your db, browser, http server or game engine with these.

Most, but not all. Languages like Rust and Zig show that you can have the performance without the landmines.

Also, theoretical performance is overrated. Almost all the things that lends themselves to speed make code brittle and incapable of future modification.

Once you’ve got your C code doing safety checks with data types that won’t break under the littlest change, the code becomes much slower than code golf would suggest. A common example is passing void pointers everywhere. You either check every call every time (aka dynamic typing) or rush everything on the idea that the programmer understands the system completely and never forgets or messes up. Better types give you all the speed AND all the safety here.

It discouraging. If the language requires you actually know what you're doing you can't hire dirt-cheap easily-replaced code monkeys to bang out your ideas and the end result is you get to keep less of the investors' money for yourself.

It can feel good to imagine yourself an enlightened master among code monkeys, yet on practice, everybody can be a code monkey sometimes, and when this happens in C/C++, it will leave a ticking time bomb in the codebase, that will lay there until a customer blows up on it, no matter how many millions went into QA of the product.

And on practice, C/C++ developers are among lower-paid programmers - probably because "banging out ideas" and producing actual programs that actually work, are valued more than language elitism.

It’s actually not true at all that C++ developers are lower paid. Rather, their pay is highly bimodal. Most work at all FAANGMULA companies is C++.

It's a feature, not a bug.