Functional Programming

Rust is not a FP language. It's an imperative language with restricted state and a few FP constructs included.

To me what makes a language FP is the mindset and that boils down to deciding to fold instead of loop and you lean to closure captures instead of declaring variables. Both sides of these are basically equivalent but having a function as the big hammer you use to nail everything together is what makes it functional programming instead of X programming with some functional ideas carried over.

When people structure a request like this they're generally after a way to really get into the ideas and the best way to do that is to use a language that's built around FP ideas. I personally recommend Clojure and OCaml. If you'd like to do Scheme via the Wizard book then that's fine as well. I don't really like the pure functional languages (Haskell and friends) because I think that state is a useful thing in small doses and don't like jumping through the extra hoops to get at it.

As someone who's been toying with Rust for a few years but hasn't written anything substantial in it yet, I really like the functional features it has. I find the pattern matching to be an incredibly clean way of managing temporary scopes that are only needed to define a single variable.

Likewise I find the restrictions imposed by the compiler to be useful for writing extremely clean, explicit code. One of the bigger issues I find with reading other people's Scala code (for instance) is that syntactic sugar of the language leads to a lot of implicitness, which can lead to a much longer period of parsing the code before it could otherwise be safely modified. With Rust it feels much more like WYSIWYG, and if there's any doubt if you can do something safely in the language, you can just mash compile till you're safely inside the guard rails.

That said, I do agree with the other commenter that it's not primarily an FP language. It is however, a highly productive language to write code in once you get past the initial learning curve, IMO.

I consider myself a relatively experienced Rust programmer (5+ years experience, 2-3 years professional).

I think it excels in most aspects, but advanced "type-meta-programming" and currying. But I think even this may be a good thing, because often higher-kinded types and lazy-evaluation is either mental overhead or leads to unpredictable performance (looking at you Haskell), so that the programmer doesn't get the idea to get too fancy, when the issue at hand is much more simple. Also often the syntax is a little bit boilerplaty compared to something like Haskell, but also this could be seen as a good thing, as everything is "documented" within it, IMHO it feels easier to read that way (as long not, something isn't hidden behind a crazy (proc-)macro (which still can be a good thing, but should be used carefully)).

Non the less I think it could improve with more advanced type-metaprogramming (and inference), because often you have like 5 lines of trait-bounds that are not really interesting for the end-user and should IMHO be inferenced (and communicated by the compiler otherwise). But I think after reading a few articles of compiler devs (like https://smallcultfollowing.com/babysteps/blog/2022/09/22/rust-2024-the-year-of-everywhere/) I think this will indeed improve soon, and it did already considerably over the time I'm programming in Rust.