It is implemented. But it requires quite a bit of boilerplate if you want to compose arbitrary closures at runtime (as you would in most FP languages), because that involves non-trivial overhead and Rust surfaces it in the code (see "dyn Fn trait objects" for how that works in detail).
Yes i know, i have wrote some FnMut closures muself. I meant, function composition should work like Lisp or Haskell, it should be very easy and intuitive, no boilerplate also. Closures in Rust, feel a lot like a hack compared to functional languages.
The way i put it, is that Haskell is a language with very strict type system, while Rust has very strict type system, and strict scoping. Strict scopes mean that an Fn closure has to be different from a FnMut closure, which also means several other complications when it comes to async.
This trade off is fine with me, but for several other people it doesn't worth it.
There's additional boilerplate involved if you want your closures to keep their captured variables around beyond their original scope in the program; in Rust, that's implemented as a kind of shared ownership which involves Rc<> or Arc<>. FP languages rely on program-wide GC for this, which of course has significant overhead of its own.
Closures are definitely cumbersome in Rust, and Lisp/Haskell/Scala programmers use them all the time. In SICP for example, they translate several math equations to code using higher order functions and closures, and it is wonderful how clean the code is, and how close to the actual mathematics.
That's what i meant it is impossible to do in Rust. From that point of view, Rust is a low level procedural language, but expressing any kind of business logic it is almost as high level as Haskell or Java.
But if we focus on error detection, then Rust is the highest level of any other PL. For example Java or Python are too low level when an error occurs. That high level of error detection is paid of course, and that is by longer compilation times.
If i had a wish though, i would wish Rust had as good closures as Haskell or Lisp.
In principle you could fix any lack of syntactic sugar (which is what leads to the "clean code" feel in Scheme or Haskell - but even Swift has custom sugar of its own for refcounting and copy-on-write) with a custom macro - which would be entirely optional, triggered by a custom attribute such as #[sloppy_code]. But that still requires a lot of fiddly implementation work.
