As Rust is getting more and more adoption, it's slowly starting to move away from “hype language” to “boring language used by normies”, like every other successful languages once did. That's a pretty good sign actually.
Rust took a lot of inspiration from the functional programming world (it has some heavy OCaml inspiration), which albeit very powerful and expressive, also come with a conceptual burden.
Rust is also in the unique position, being low level as well as functional, which means it will always be alien no matter what programming background you have.
In order to guarantee memory and thread safety, it also adds a few restrictions. Some are fundamental (mutable XOR shared, move semantic) others are/were temporary implementation limitations (like lexical lifetimes, or arrays being second class citizens, or the `impl` keyword being usable only in a few cases). In that regard, Rust has become much simpler since it was released 6 years ago, but it still has some margin for progress.
> Rust took a lot of inspiration from the functional programming world (it has some heavy OCaml inspiration), which albeit very powerful and expressive, also come with a conceptual burden.
> Rust is also in the unique position, being low level as well as functional, which means it will always be alien no matter what programming background you have.
Having worked with Haskell and generally being very comfortable with functional programming (whether or not I'm happy about the astronomical complexity of Haskell as a language with extensions is another story) and also having a lower-level background I can tell you that the offerings of Rust as a "functional" language (this is generally so ill-defined that you can call basically anything functional) are extremely slim and that I'd never choose it for any of that.
Tagged unions and `match` expressions might make for a functional language to a lot of people but these things are orthogonal to functional programming. They're nice to have, but to harken back to the original topic; Zig has tagged unions and can `switch` on them to unpack payloads just fine.
Like I said, I think FP is ill-defined but even with that in mind it's a stretch to say that Rust is functional.
Most people, I would hope, would agree that function composition is more an inherent feature of FP and honestly I've never seen a particularly compelling argument for Rust having a reasonably useful solution to that. Stitching together methods is one step, but it only gets you so far and isn't as generally useful as what most ML-descendants would give you.
On the balance i find functional languages to be easier than oo languages, so I highly doubt that functional is the reason for complexity. In fact as an FP programmer, I find it's very possible to write zig in a functional style (imports feel like modules), in spite of the oo sugar that zig structs have been endowed with.
Is it really boring that you have to learn 20 different features to do 20 different things? There is a certain economy at play with feature sets that the author brings up that has nothing to do with "boring" or not; having to learn a ton of different things and always feeling like there's probably some tailor-made thing you should be using for exactly your problem is not boring, it's just less productive when working.
You're missing the point here: I meant “boring” as “it's been six years already, we want new toys”. The more it ages and gains adoption (which really skyrocketed in the past two years), the less “cool” Rust will be.
You cannot be “cool” and “mainstream” at the same time.
I don't disagree about any of what you said here in isolation, but I'm not sure that the complaints that the author has stem from Rust being inherently more popular.
Sure, adding features is generally a sign that you're trying to capture/retain users (I recently learned that weak equality operators were added to JavaScript for this exact reason and Brendan Eich regrets it *a lot*), but at the same time it feels like things could be more cohesive than they are.
But yeah, I agree that hype trains lose momentum when things become more common. With that said, I don't really feel like Rust is popular/common enough to lose hype. Basically no one uses it in production in comparison to the obvious alternatives and it'd be a bit odd for it to lose hype so soon.
> but I'm not sure that the complaints that the author has stem from Rust being inherently more popular.
These complaints made the top of HN today, not 5 years ago (when Rust for embedded was way less mature and convenient), for a good reason. And notice that this person isn't advocating that Rust is too complex and you should keep using proven tech like C or Python for doing real stuff, they are advocating using a brand new experimental language, with a radical new design, whose compiler keeps crashing and which still makes breaking changes every once in a while[1]. This specific article is a really good illustration of the hype train moving on.
> but at the same time it feels like things could be more cohesive than they are.
The Rust team attempt to make the feature as cohesive as possible (and compared to a language like C++, they are doing a pretty good job at it) but nothing is perfect. I'm curious if you have specific examples of features that you don't think are cohesive though. (One example I can think of is the old `macro_rule!` vs procedural macros, but maybe there are others).
> With that said, I don't really feel like Rust is popular/common enough to lose hype. Basically no one uses it in production in comparison to the obvious alternatives and it'd be a bit odd for it to lose hype so soon.
Hype is a multi-level thing: the Rust hype is still growing (it still makes the front page of HN almost every day), but the most avant-garde hackers are moving away from it. That's nothing unexpected.
[1]: I'm not bashing Zig in any way, nobody expect such a recent language to be polished already!
