Having programmed C for soon 30 years, I absolutely agree with you that C is the problem.

But often you just need to get the job done, and have limited options available.

Perhaps in 50-100 years, people looking back at software from this era won't be able to understand how we managed to make it work at all.

I haven't met or know anyone mastering C/C++ (especially C++), and doubt I'll ever hear about one.

I know plenty of C masters, and a few C++ masters. If you want to meet C++ masters, go to cppcon or get a job writing systems software at a respectable C++ shop.

I’d say I had a working knowledge of C++ after about a year ramping up on a codebase based on a mature C++ framework.

That was after years of writing reliable, performant C code. My C++ is now significantly better than the C I can produce, on both fronts, and at the same time.

I’m also much more productive as a side effect of that.

I doubt very seriously that any of those C masters can recite by heart the 200 plus use cases of UB recognized by ANSI C.

> I haven't met or know anyone mastering C/C++ (especially C++), and doubt I'll ever hear about one.

C can definitively be mastered. C at it's core is pragmatic minimalism. The basic ideas are very simple. If you want to be a language lawyer and know the standard completely (including all historical accidents), it can get complex, but still manageable. But anyways, you shouldn't be a language lawyer. That's not C. Make maintainable programs instead, stay in the middle of the road.

C gets out of the programmer's way. It's not about mastering C, but about mastering programming. And while I agree there's much bad C software out there: I haven't seen one maintainable non-bloated Java project. Here is one master of C that I'm sure you know: Linus Torvalds. Of course there are many, many more. Just remember it's not about C, but programming machines in general.

> I haven't seen one maintainable non-bloated Java project

I also haven't seen one large-scale network-facing C project written using reasonable development practices (i.e. not absurdly expensive formal verification) that hasn't had some sort of terrible remote code execution vulnerability. By contrast, Java programs tend to be far less vulnerable to this kind of problem. (The closest thing is probably bugs with attacker controlled java.io.Serializable, which while severe are much less frequent than RCE in C programs.)

> Here is one master of C that I'm sure you know: Linus Torvalds.

I agree that Linus is a master of C. Linux is also an excellent example of the above problems with C.

> I also haven't seen one large-scale network-facing C project written using reasonable development practices (i.e. not absurdly expensive formal verification) that hasn't had some sort of terrible remote code execution vulnerability.

This has gotten a lot better with static code analysis (clang-analyzer, Coverity, ...) and whitebox-fuzzing (libfuzzer, afl, ...). Both simply point you to the bugs and don't require a formal spec.

Together with Valgrind, these tools have revolutionized C programming for me.

These tools are important for legacy code or code that cannot be written in any language other than C. They do not bring C code anywhere near to code written in other languages in terms of security and correctness.

Plus those tools are not available in all C compilers, specially in the embedded world.

I believe BIND9 has never had a remote code execution vulnerability - plenty of denial of service vulnerabilities, though, because it kills itself when it detects memory corruption.

I wouldn't say "mastering C" should imply "never have any security issues". And many vulnerabilities are conceptual and don't have anything to do with the use of C.

Use your tools wisely. Architect programs for clear data flow. Validate inputs as soon as possible. Don't do (de)serialization by hand.

By all means use a managed "memory safe" language if you have many data accesses that are not behind a validation gateway. But for large amounts of data or complex software, that's still not an option. C is still the only language in which I can write software of advanced complexity - because it does not get in my way.

The entire industry has been successfully writing programs that process "large amounts of data" and "complex software" in languages other than C for decades.

Counter-examples: Kernels, Game Engines, Software with lots of small "objects". I once had to write a SAT solver in Java (dozens of millions of clauses) and it was a disaster which I could only rescue by converting to highly unidiomatic Java code. It would have been much more straightforward in C.

> Kernels

Mesa/Cedar at Xerox PARC, Topaz at DEC/Olivetti, Oberon at ETHZ, JavaOS at Sun, Singularity/Midori at Microsoft Research

> Game Engines

Unity is slowly rewriting parts of their C++ pipeline with C#, after their IL2CPP compiler got mature.

Then there are game engines like Xenko being done.

Also being with one foot into games since the 80's, I remember the transitions "Pascal/C are too slow, we stick Assembly", "C++ is too slow, we stick with C", now we are in "JavaScript/C#/Java are too slow, we stick with C++" phase.

> C can definitively be mastered.

If that's true, how come there are almost no widely used network facing C programs that didn't have plenty of security vulnerabilities?

(Anything written by Daniel J. Bernstein doesn't count, because there's no way he's a mere mortal. :))

OpenBSD has done a great job, especially if you look at what they achieved, how fast they got there, and what resources were at their disposal.

Qmails direct competitor Postfix? Postfix has more, but Qmail has one with a higher score: https://www.cvedetails.com/vulnerability-list/vendor_id-8450... vs https://www.cvedetails.com/vulnerability-list/vendor_id-86/p...

Postfix is also much more widely used than qmail.

Even djb had flaws in his C code despite being a semi-god. It took a $10k bounty and several years to be found but it was there !

Which language has? Keep in mind market share, so don't say Go.

for, while, do...while, recursion, goto: is not a sign of "pragmatic minimalism" unless one choses to define it tautologically as "what C has".

"recursion" is not a concept in C. Just function calls. "for" and "while" are very simple concepts and basically the same. They are very simple and well known idioms and not C specific. Most languages have both - not a big deal. I use "for" mostly for iterating over arrays, and I have otherwise mostly while loops and while(1) loops with manual breaking.

Goto, you just can't do without it.

Also not saying that in some cases even C is too much abstraction. But in general, its memory abstractions and its function call abstraction have proved to be very effective helping humans develop in a modular fashion.

> Goto, you just can't do without it.

Strange, the last time I used it I was still doing Basic in the early 90's, or when I do some Assembly programming.

So yeah, we can do without it, as long as the languages are powerful enough.

I do find forward gotos useful in C. For error handling and breaking out of nested scopes. But only when goto is simpler and easier to understand than the alternative.

Not saying there's no use for backward gotos, just don't remember ever needing them. Maybe they could be useful for some C code generation cases or perhaps for retrying some operation?

What really annoys me are C++ exceptions used for flow control. Surprise gotos. I loved exceptions long ago at first, but over time the feeling has shifted more and more towards hate. Exceptions make code bases so much harder to understand. Especially when combined with inheritance.

> "recursion" is not a concept in C. Just function calls.

There are indeed C compilers that don't support recursion (or function re-entrancy). What does the standard say about stacks?

I'm not a standards guy, so I might be wrong, but this is the only reference to recursive calls that I could find from the C11 draft [1], Section 6.5.2.2 item 11:

    Recursive function calls shall be permitted, both directly and indirectly through any chain of other functions.

Stacks, I don't know. I only care about the concept (and semantics) of function calls. The call stack is an implementation detail. I wouldn't be surprised if the concept of a call stack was not part of the standard.

[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

Indeed, it's not. In the case of what we'd usually call stack-allocated variables, the C standard just uses the phrase "automatic storage duration", and defines their lifetime without explicitly referencing a stack:

> For such an object that does not have a variable length array type, its lifetime extends from entry into the block with which it is associated until execution of that block ends in any way. (Entering an enclosed block or calling a function suspends, but does not end, execution of the current block.) If the block is entered recursively, a new instance of the object is created each time. The initial value of the object is indeterminate.

Pragmatic == close enough to all of the popular and contemporary assembler flow control constructs.

> C at it's core is pragmatic minimalism.

Pragmatic minimalism as it was for the hardware at the beginning of the 1970s, to be exact.

The C machine model is still the only model I can easily program and not make a mess. And without being a hardware architecture expert: Has so much changed on the assembly level? And what other languages are truer to today's machines?

None of them are, not even Assembly, unless the CPU executes the opcodes directly in hardware without micro-code help.

The C machine model says nothing about vector instructions, instruction re-ordering, NUMA, GPGPU, IO ports, Harvard architecture, multi-core.

As of C11, the C machine model does (finally) include threads and memory ordering, so at least you can say it says something about multi-core…

Modern C compilers do enormous job of optimizing C code, despite its shortcomings like the lack of distinction between pointers and arrays. You don't need to worry too much about that, maybe you'll need to sprinkle vectorization intrinsics or assembler code if the compiler isn't smart enough, or to add a couple of memory barriers.

Would mostly sign that, but not without inspecting security or performance critical code in disassembler.

Modern compilers are still rather bad at vectorization. What's worse, those optimizations are often unstable. A small change might make code several times slower. Performance regression tests and when that fails, vector intrinsics are a must.

I'm curious about what other languages could be used in place. Maybe ADA ? it's both generic oriented and low level.

A friend of mine who is working in HPC research (high-performance computing) generates CUDA kernels using higher-kinded templates. He can instantiate you a

  template<template<class>, template<class, template<uint>>, class>

before breakfast.

We've been hearing "how long will the problems of C persist" mere persist before people realize there might be reasons it's the most successful programming language yet invented?

There are definitely reasons behind C's success. Most important was that it was the language of Unix, which spread like wildfire in the '70s and '80s because it was free.

There are equally important reasons why C's usage has been in steady decline from the '90s to today.

> Most important was that it was the language of Unix

More important was it was the only language that really worked on DOS, which ruled the computer biz for 10 years. I would guess 80% of programming was done for DOS, and C was a very good fit for the 640K systems.

On my corner of the planet we were using Turbo Pascal, Turbo Basic, Quick Basic, Clipper, FoxPro, DBase.

C and C++ had no special place on the spectrum of programming languages usage, unless we were porting code between MS-DOS and UNIX.

Until it was time to move into Windows, and anyone not using C or C++ started to be left behind, manually writing FFI wrappers (e.g. Turbo Pascal/Delphi) and we eventually migrated to one of them.

None of that is true at all. Turbo Pascal was hugely popular on DOS in the 1980s into the early 1990s. It wasn't until Windows 3.1 that Turbo Pascal really started losing market share to C. You are also completely forgetting about Apple. IBM PC compatibles did not even pass 50% market share until 1986.

Well, sure, but Microsoft wouldn't have chosen to promote C if not for the success of Unix. :)

Quite true, and on those days Microsoft was equally promoting Quick Basic and Quick Pascal, while writing MS-DOS in pure Assembly.

No, C got famous thanks to UNIX, just like we have to use JavaScript thanks to the browsers.

Path dependency is why. It's not complicated, it's just expensive to overcome.

I think only recently has a language been invented which has a good chance of replacing C and that's Swift. It's like C++ done right, it's user friendly, pragmatic, backed by a huge company and doesn't use GC.

Reference counting is a GC algorithm.