"Just about every software project written has some serious bugs"

There, fixed it for you. Seriously, vulnerabilities and bugs are found everywhere not just in C.

I've been programming for 35 years, in so many languages I lost count, and every time I've seen the 'let's not use C because it'll lead to bugs' it was to be replaced by another thing that was ALSO leading to bugs, and/or become so bloated it was in itself... a bug.

> Seriously, vulnerabilities and bugs are found everywhere not just in C.

The black-and-white security fallacy again!

The simple fact (and this is a fact, not an opinion) is that the most severe security problems—remote code execution, in particular—are found way way way more in programs written in C and C++ than in other languages.

I strongly agree with your point in general, memory safety is a major problem with C/C++ to an extent that is not found in other languages. Even worse, these often become problems long after they are written when the compiler gets "smarter" and does a trick with your code. Call it "code rot" or whatever you want, but it happens a lot more and a lot faster on C/C++ than other languages.

However, the nature of where C/C++ code is used does lend itself to severe problems. When you have a JVM vulnerability, you shouldn't be able to get any farther than a regular user with only sandbox privileges. When you have a kernel vulnerability, by definition you have the keys to the kingdom.

Of course there are always holes that can be used to escalate, but that also comes back to the problems of having a primarily C/C++ ecosystem...

Per unit of code or as an absolute value? That's significant, but not even the whole picture. It's trivial to have a low (absolute and per-unit) number if the total number of units is low, for example. So by itself your fact is almost useless.

The big problem with C is the memory safety issues. It is extremely difficult to write C code and be safe from malicious input. If you use a memory safe language these difficult issues are erased.

I realise the compiler/runtime can't stop all bugs but fixing these simple errors goes a long way to producing robust secure software.

I am sorry, but there's nothing difficult about it. Tedious, yes. Difficult? No.

I hope you will agree that there are things where C is not the optimal choice (e.g. you wouldn't choose C for writing scripts). Many people argue that C is still suitable if you need maximal performance or do stuff that is very close to the hardware, like operating systems. Now, people who say that C shouldn't be used at all are just convinced that even in those applications there are now better choices than C. Safer languages like Rust exist that at least claim to fill the same niche as C.

A: "Let's not reuse syringe needles, it leads to spread of HIV".

B: "I've been using syringes for 35 years and clean needles won't get rid of HIV entirely".

Well no duh. But that isn't really a counter argument.

> become so bloated it was in itself

Whereas C is the pinnacle of expressiveness?

I don't think it sensible to single out C for having serious bug. It should be most software projects have serious bugs.

Your criticism lacks constructivity. What do you propose we replace C with?

Whatever doesn't have extremely tight constraints (CPU, memory, embedded…) should probably use garbage collection. Now your language can throw a nice exception (or otherwise cleanly abort the process) before any memory corruption (and subsequent vulnerabilities) can occur.

Otherwise, I'd say try something like Rust. And if Rust doesn't make the cut, maybe go write your own C-like dialect, with less undefined behaviour.

Depends on what you are writing. C isn't 100 percent replaceable right now but the more people bitch about it and support the alternatives, the better for the future.

Just curious, what are us C apologists supposed to be apologizing for:

- A lack of suitable replacement for C?

- C is too ubiquitous?

- C has been an integral part of most of the best software ever written?

FYI, "apologist" is often not used to literally mean "one who apologises", but rather "one who defends"[1], with a negative connotation (at least in my experience).

I would guess the "C apologism" in the original comment is referring to defenses of C that pretend C is safe "in practice" (or "for people who know what they're doing") or minimise/ignore the strong correlation between the use of C and serious problems/vulnerabilities.

[1]: https://en.wiktionary.org/wiki/apologist

Ada has been a suitable replacement for C since the early 90s when GNAT was released. Prior to that there were still plenty of suitable C replacements given a little work, like Pascal and Oberon.

Agree with the first two but the last isn't saying much. C has been an integral part of most software ever written, best, worst, and everything in between.

Rust?

C enables - in my opinion - better abstractions than languages which constrain you to the use of their suite of abstractions. I'd include C++ in that, and especially template-heavy C++.