There is a world of difference between the complexity of C and C++. C is in principle quite easy to understand (besides some syntactic quirks), similar to Turbo Pascal back in the day. Go, on the other hand, has various features that are not so easy for beginners to understand (e.g., interfaces with all their rules, or value vs. pointer receivers with all their complex consequences). Since the introduction of generics, the complexity of Go has taken a leap forward, moving even further away from C and closer to C++ in terms of complexity.
You're probably right that for trivial examples C is, in principle, the simplest to learn and understand. But in reality, non-trivial C projects come with complex build systems, makefiles, macros, endless compiler flags... I've found it pretty hard to, for example, fork a moderately-sized C project and modify it. Hell sometimes even building it is a challenge when you don't understand make/build system errors and how to set up and configure C projects.
Go, however, i could just get up and running. Simple to use modules, simple to import dependencies, simple to build projects, great centralized documentation. Now granted do i fully understand all the nuances of things like pointer receivers and generics? No, but i don't really understand memory allocation in C either to be quite honest, and I've spent more time trying to understand C in my life than i have Go (please understand: extremely little in both cases)
Rust does seem similarly impenetrable honestly, except that it seems much easier to build and manage Rust projects. But I definitely can't even just read Rust code and get it the way i can Go (or even C)
C was easy to learn, hard to use. C++ was hard to learn, hard to use. Rust was hard to learn, easy to use. Rust was only one of those I was able actually learn and use.
Saying project directory structure is complex is IMO crazy, since a fair comparison would be to general package/dependency management on C++ which is a brain explosion.
Where they do have a point is that I would hope, we can create a language that is at the same time fast, safe and simple to use. Right now we have a tradeoff triangle. Rust is safer than C++, about as fast, and arguably harder to use. Something gives.
The article absolutely has a point that C is trivial to pick up, and surely that fueled the explosion of software.
It's also engaged in an odd two-step where it conflates C and C++, championing C's simplicity in contrast to Rust's complexity... and then just doesn't address C++'s complexity, as though it's interchangeable with C. The notion that Rust developers are running into quirks with tooling and this is reason not to use it in preference to C++ is ludicrous.
The note that Rust cannot fully replace C++ as long as it depends on using it for its key compiler backends.
Finally even if it is a bubble, AI driven programming is making specific languages irrelevant, eventually only AI language runtimes will need fine grained control how everything works, at the bottom layer.
Maybe the future is an AI language compiler generating machine code directly, with similar productivy as Xerox PARC workstations, Lisp Machines, or Bret Victor ideas.
Rust can win against CPP if AI can understand its docs better than CPP's :D
Generating current programming languages is only a transition step, just like Assembly programmers were suspicious of the first optimizing compilers and expected multiple steps, having the compilers generating Assembly they could inspect, and only then run the Assembler on that.
We need to take the Alan Kay point of view, not what AI tools can do today, rather what they might look a few decades down the line.
You've got to be kidding me...
Memory safety is a huge benefit in myriad scenarios. I would call it the rule, not the exception. Pair that with competitive performance and you have something really compelling. I don't know enough Rust to really speak to its tradeoffs, but the above just seems like a dumb point to try to make.
And regarding the "hype cycle," Rust is old enough now to have survived many actual software hype cycles, so this claim of us finally getting to the middle of it now, which isn't really justified in the article, also doesn't seem to stick.
When making bold clickbaity claims like the author does, at least get your terms right...
It is actually a misnomer. Your interpretation of the graph is correct, but the phrase actually means the opposite.
Rust is one of these topics. If you want to be flagged and down voted, just write a critic about Rust.
Even tell about this is a motive to be down voted.
These two languages look like they have a weird kind of "protected and special status" on HN. Other programming language don't get anything like the push and special treatment that these do.
[1]: https://archive.md/sJRyf (TIOBE Index Novemeber 2025)
Nonsense. It's not all that hard to find well-received stuff on HN critical of Rust (e.g., from a quick search there's [0, 1, 2] and plenty more, especially around async and/or deps). The key is to write substantive/thoughtful/constructive criticism. In fact, that applies in general - substantive/thoughtful/constructive articles/comments are much more likely to be well-received no matter their topic.
This article does touch on some of Rust's weaknesses/pain points, but does an absolutely atrocious job of doing so. Right off the bat you have this:
Example comparison (small benchmark):
# C++ (g++)
$ time g++ main.cpp -o main
real 0m0.4s
# Rust (cargo build --release)
$ time cargo build --release
real 0m9.7s
And it's pretty much downhill from there. Like this:
> Suddenly, the compiler starts screaming:
error[E0515]: cannot return value referencing local variable
The code organization example is yet again not an apples-to-apples comparison. It's also straight up wrong to boot.
The migration decision tree is inconsistent as well. If "memory safety is your #1 priority", then C++ with sanitizers is definitely not a viable option.
So on and so forth. If you want to write Rust criticism and be received well, this is definitely not the way to do so.
[0]: https://news.ycombinator.com/item?id=40172033