I don't think it is contentious at all to say that C++, Ada, and Rust are all in the top five most complex languages in the history of software. All three tried to be low-level languages that appear high-level.
But Rust isn't complex: there aren't many features interacting in a special way with one another with a combinatorial explosion of interactions you need to know in order not to shoot yourself in the foot. (Move semantic difference between Rust and C++ are a good illustration of that).
Actually, in terms of number of different features you'll encounter when onboarding a new project, Rust is far behind JavaScript and PHP (PHP being the biggest example of how feature bloat doesn't kill a language, even if your language is targeted at inexperienced developers).
"Why I rewrote my Rust keyboard firmware in Zig: consistency, mastery, and fun" https://kevinlynagh.com/rust-zig/
In absence of good metrics for the kind of complexity we're trying to discuss I think we kind of have to rely on these sorts of first-person subjective reports from the field.
But it does need to be said, that the approach he was using with Rust was absolutely not the right tool for the job. The author should have been using traits. That's what they're for, and they definitely aren't an obscure language feature.
And that being said, the author mainly complains about features that also exist in C (macros and ifdef, and Rust's version are easier than the C one), would you call C a too complex language because it has macros and ifdef? (I actually think that C is one of the most complex programming language ever written because you need to store too much invariants in your head otherwise it's UB, but ifdef and macros aren't at stake )
- - - -
> I actually think that C is one of the most complex programming language ever written because you need to store too much invariants in your head otherwise it's UB, but ifdef and macros aren't at stake
Like I said, without metrics we're just trading subjective anecdotes.
Metrics for complexity of machines is a subject I find fascinating, ever since I read Ashby's "Introduction to Cybernetics" wherein he asks the question "How can we measure the complexity of a machine?" in the context of a formal system for describing machines (Cybernetics.)
There is also the concept of "Kolmogorov complexity" https://en.wikipedia.org/wiki/Kolmogorov_complexity
We could compare the sizes of compilers for C and Rust.
We could teach each to different randomized groups of students and see how quickly people learn to write (safe!) code in each.
Yes, this one guy made a wrong turn once. If you want to conclude from one user making a mistake that a language is complex then you're just going to conclude that programming is complex … Everyday, with every language under the sun, people make mistakes, great discovery.
I'm not blaming “the user®” here, I'm blaming the blog post writer who makes a mistake and concludes that his tool is responsible for it and that he should tell the world how bad the tool is.
> Like I said, without metrics we're just trading subjective anecdotes.
Well that sentence is pretty ironic given the previous one, nevermind.
> We could compare the sizes of compilers for C and Rust.
I wonder what conclusion you'd draw from such a comparison. That assembly is the least complex language in existence, followed by Brainfuck and Chicken?
> We could teach each to different randomized groups of students and see how quickly people learn to write (safe!) code in each.
Oh I actually like this one. For Rust, you'd need to run a study to find out, but for C the answer is trivial: Never. Nobody on earth know how to write safe C. Not even DJB, not even Theo de Raadt, or Richard Hipp, or Brad Spengler. For almost 50 years, the brightest minds of computer science have tried to write safe C code, and consistently failed. Can we conclude that this language is a little bit too complex for humans, or should we wait a few decades more?