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.
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.