Several of the arguments are not compelling.

For instance:

"The C language is not just the language itself but all the developer tools developed for the language. Do you want to do static analysis on your source code?"

This is a finite problem set. For instance, AI could auto-create useful toolings eventually. And even without AI, people can. Even more so if a new language is designed with that in mind from the get go. So, perhaps it would be a lot of effort, but this is really not the reason why C is so dominating.

> The uncertainties of a new language

> Before a language has matured, it's likely to have bugs and might change significantly to address problems with language semantic.

Here I somewhat agree. Another language is different, that is true, and may not be better, that is also true. I am still not convinced Rust is better than C, for instance.

However had, I also don't this this as unsolvable. Many new languages are in part better than C. I mean, I notice this when I write ruby code and C code. Let's ignore the speed problem; and the fact that ruby is written mostly in C (which kind of shows that C dominates everything). The ruby code I write is about 1000000000x easier to understand, simpler and almost always shorter than C. There is no comparison here. Ruby is the better programming language. C is faster and more efficient. And this is also significant. My prediction is that a language that would be able to replace C, needs to target both the speed issue without compromise AND the efficiency of writing code, be it ruby-like, python-like and so forth. And neither of these two languages try to replace C either, so they don't quite count here.

> And what about maintainers? Sure, an open source language can be forked, but I doubt many companies are interested in using a language that they further down the line might be forced to maintain.

This is a problem, but you have this problem with corporations too. For instance, Go is controlled by Google, as is Flutter/Dart. Google can babble that everyone can contribute but the reality of the situation is that Google decides what happens; same with the adChromium code base. Personally I really don't want corporations to dictate their world view onto a language. Committees can also have problems or be bribed and what not, we can see the chaos in the C++ committee too, even without bribery - stupidity often rules supreme. But by and large, I much prefer single benevolent dictators or indepedent (as much as possible) committees than mega-evil mega-huge greedy corporations controlling a language. This does not automatically mean a language is better or worse, either way, but it is a preference for me. And I know for a fact that many others somewhat or strongly agree with this too, except a few die-hard Google fanbois (but most of them are employed by Google anyway, so their "opinion" does not count; I see the same problem with shopify and ruby, by the way, it's really interesting).

> 3. The language might just not be good enough > Is the language even addressing the real pain points of C? It turns out that people don't always agree on what the pain points with C is.

Yup, that is also true, see Rust. On the other hand, I think cargo is really useful, and even C++ agreed. I think C also did not that long ago, but boy, for many decades C thought that easy download of add-ons is not needed. C changes very slowly. I understand that this is often nice, but just as in the example of cargo and what not, this was really STUPID of C to not change here.

Other than that I agree on the general point. Many changes are also idiotic in other languages. Ruby incorporated many idiotic changes too; thankfully I can avoid most of them so I just ignore them indeed.

> A new language will naturally have a much smaller pool of experienced developers. For any middle to large company that's a huge problem. The more developers there are available for a company, the better they like it.

That's also true, e. g. look how few developers use D. I think the only way to change this is to make the language SIMPLE, EASY but also efficient at the same time. Like python. Though python is not aiming to be a replacement of C, so it does not count - but people are quite easily able to learn and use it. C is much harder to use; just give new recruits a task to implement things that manipulate memory and pointers a lot.

> The C ABI is the standard for interoperability

Any language can have that too so I don't see this as a problem.

> 1. Better syntax

> Having a "better syntax" than C is mostly subjective.

Wrong. And this is what 99% of those "I will replace C with my language XYZ" get wrong. The syntax they use usually SUCKS. They think syntax matters absolutely not at all. They are wrong. But they think they are right, so they write a useless pile of crap and then wonder why nobody writes in that language.

> 2. Safer than C > Any C alternative will be expected to be on par with C in performance. The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable.

This is partially correct, partially wrong. Rust showed that safety is a feature; C++ agreed. C does not. I understand the speed penalty, and I am not saying you need to make safety a pseudo-religion like Rust did, but that trade-off needs to be determinable by the code author. So, some code can be fast like in C; for other code the trade-off may be different. A language should make it super-easy to distinguish here. Rust does not make it super-easy. C even less.

> Programmer productivity

> First of all, pretty much all languages ever will make vacuous claims of "higher programmer productivity". The problem is that for a business this usually doesn't matter. Why? Because the actual programming is not the main time sink. In a business, what takes time is to actually figure out what the task really is. So something like a 10% or 20% "productivity boost" won't even register. A 100% increase in productivity might show, but even that isn't guaranteed.

Also totally wrong. Yes, writing code is not always the bottle neck, but what he forgets is the simplicity of writing good, fast code. If it takes 5 hours to write 3 lines of code, something is wrong with the language itself.