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.
Complex is a poor adjective to talk about Rust: Rust is hard because there's one key concept one must learn before doing anything: ownership. And this concept (at least in the Rust incarnation) is completely alien, so you need to unlearn how to code before re-learning it the Rust way. This is hard and that's why Rust have a tough learning curve.
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).
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.
There is a valid point here, which is that it's sometimes difficult to know what "the right thing to do" is in Rust, because it is a large language. I agree and can sympathize. I happen to like Zig also, FWIW.
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.
This article has been extensively discussed here and on reddit, the authors faced a problem, did not seek help, and solved on his own it in a pretty convoluted way involving compile-time metaprogramming with macros. As pointed elsewhere, his problem is usually addressed using the type system (enums or traits). You can write a non-standard over-engineered solution to a problem with any programming language, that doesn't mean the language is complex. Zig being especially designed around compile-time meta-programming, it's not a surprise that the resulting code looks much more straightforward.
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 )
You (and dralley) are missing the point: the dude made a wrong turn with Rust and didn't with Zig. You can blame the user all day long but at the end of the day what leverage Rust devs have is not in the user's head, eh?
- - - -
> 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.)
> the dude made a wrong turn with Rust and didn't with Zig.
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?
Complex is a poor adjective to talk about Rust: Rust is hard because there's one key concept one must learn before doing anything: ownership. And this concept (at least in the Rust incarnation) is completely alien, so you need to unlearn how to code before re-learning it the Rust way. This is hard and that's why Rust have a tough learning curve.
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).
In re: "complexity" of Rust here's something relevant and interesting that was on HN front page the other day:
"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.
There is a valid point here, which is that it's sometimes difficult to know what "the right thing to do" is in Rust, because it is a large language. I agree and can sympathize. I happen to like Zig also, FWIW.
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.
This article has been extensively discussed here and on reddit, the authors faced a problem, did not seek help, and solved on his own it in a pretty convoluted way involving compile-time metaprogramming with macros. As pointed elsewhere, his problem is usually addressed using the type system (enums or traits). You can write a non-standard over-engineered solution to a problem with any programming language, that doesn't mean the language is complex. Zig being especially designed around compile-time meta-programming, it's not a surprise that the resulting code looks much more straightforward.
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 )
You (and dralley) are missing the point: the dude made a wrong turn with Rust and didn't with Zig. You can blame the user all day long but at the end of the day what leverage Rust devs have is not in the user's head, eh?
- - - -
> 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.
> the dude made a wrong turn with Rust and didn't with Zig.
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?