Today is easy (finally we have Rust, Zig, Odin, Swift, Go etc that show marked improvements), but the op is correct: A lot of progress was stalled because people defend sub optimal tools.
Every time somebody suggest "but C is wrong" the answer was "You should not do the wrong, be careful every time and things will be fine!"
P.D: Yesterday we have pascal/ADA/effiel/ocalm and others, but the major issues is that C/JS should have be improved to remove the bad things, and add the good things. Is not as if what or why to do it was a mystery, it was just the fear and arrogance against change.
And this cause too much inertia against "reinvent the wheel" and too much hate against anybody that even try
He seems to have mistaken his personal opinions on which languages and language features are good for some objective truth.
Ironically, that’s part of why we can’t have nice things. People who aren’t open to other viewpoints and refuse to compromise when possible impede progress.
Well, sure, age is part of it. I would hope languages coming out 40-50 years after their predecessors (in the case of Rust following C/C++) would have improved upon those predecessors and learned from the ideas of computer science in the intermediate years.
(Coincidentally this is one of my chief complaints about Go: despite being about the same age as Rust, it took the avenue of discarding quite a lot of advancements in programming language theory and ergonomics since C)
Go has a much different set of design goals than Zig, Nim, or especially Rust. Go is really for people who want a few major improvements on C like easier builds, faster builds, higher-level standard string handling, direct support for some form of concurrency, an optional GC which defaults to on, and a few syntax tweaks - things that a modern C might have that were not going to make it into a standards revision. Rust, to support ownership and the borrow checker at compile time, had to build a useful language around that hugely helpful but quite restrictive requirement. They subsequently went different directions than the Go team on a lot of the other language features. Zig, Nim, and D are something in between those extremes in their own ways.
As someone with a background of a lot of time with Perl and the Pascal/Ada family who was rooting for Julia, Go strikes a good balance for me where I would have used Perl, Python, Julia, Ruby, or shell for system tasks. I haven’t done a lot of work in Rust yet, because in the infrastructure space speed to implement is usually more important than performance and Go is a lot faster already than Python or Ruby and because my team as a whole has much more experience with it. I certainly appreciate why the folks at work who do the performance-critical network and video software use mostly Rust to do what they used to do in C, Java, or C++.