As an outsider with only a very superficial understanding of Rust, it seems that Rust has all the right features for functional programming, except for immutable/persistent data-structures exposed by the standard library.
This is the missing link for people wanting to do FP in Rust and even though this is an issue of standard library and not necessarily one of language, this will be a source of pain for people wanting to do FP in Rust, as FP means working with referential transparency, which begets immutability. This I think is worth mentioning, being the biggest road-block when wanting to adopt an FP style in any language - after all, any language that supports higher-order functions can be used for FP (or OOP) with varying levels of pain.
Again, as an outsider with a superficial understanding of Rust, it seems that Rust will make FP enjoyable in a language that doesn't need a garbage collector. But judging from articles and announcements made, Rust's primary objective to make concurrent programming safer isn't necessarily to make immutability effective, but rather to limit/control both shared reads and writes. And I can think of contexts in which you don't necessarily want that - after all, the shared reads of an immutable value are embarrassingly parallelizable, persistent data-structures working really well in say single-producer multiple-consumers scenarios. Plus immutable values are for having referential transparency and the common concurrency issues that we are commonly seeing are only a symptom. Truthfully, Rust must allow specialized algorithms and low level code, so I expect it to give the possibility of choosing your path instead of forcing a solution down your thrown.
But herein we are ending with a problem also exposed when working with C++. People have been doing FP in C++ with varying levels of success. But the problem with persistent data-structures that are doing structural sharing is one of memory management. It's much harder to implement persistent data-structures without relying on a garbage collector. LISPs that encourage an FP style, Ocaml, Haskell, SML, F#, Scala and all languages advertised as FP I can think about are garbage collected. Rust can use an optional garbage collector for "shared references". But that negates the biggest advantage when using Rust, the community is moving away from shared references and Rc/Arm touched in this article would be awful solutions to this problem.
Therefore I hope seeing progress in seeing a library of immutable data-structures that I could use in Rust or at least advice on how to deal with effectively immutable data-structures or something.
On the bright side - Rust's type system seems to be solid (yay generics, yay type-classes), which means it's just a matter of time before the libraries will get there.
I think once you gain a more than superficial understanding, you'll be happy with Rust. :)
> the shared reads of an immutable value are embarrassingly parallelizable,
This is absolutely true, and Rust lets you do that. You just have to dot your is and cross your ts: https://gist.github.com/steveklabnik/8de9b9b0ae2e45383d85 Rc adds reference counting, to ensure that this reference will be okay for the duration of all of the threads. If you just used a regular old boxed value, one of the threads could invalidate the reference.
That's just one example. As you say, there'll be libraries eventually: people have been focused on the language itself, and given how easy Cargo makes it (will make it) to share libraries, I wouldn't be surprised to see an awesome persistent/immutable data structures library appear.
Well I definitely want to play with Rust and seems really promising, even from the point of view of a superficial observer.
My impression is that reference counting, while deterministic, has some problems due to reliance on atomics (which gives rise to contention issues, even in cases in which intuitively there shouldn't be any contention) and because of cyclic references - but maybe this isn't such a problem in practice when used for persistent data-structures or if there are multiple versions of an interface suited for different scenarios.
My intuition has definitely been proven wrong before. And I have high hopes for Rust - seemingly being a language allowing for FP and for fine grained memory management while not setting my hair on fire :-)
Rust actually has two different reference counted smart pointers: `Rc`, which uses non-threadsafe reference counting, and hence is not sendable across thread boundaries; and `Arc`, which uses atomic reference counting and can be send across thread boundaries.
You can definitely create leaking cycles with both though, but Rc and Arc also support Weak pointers to safely break up cyclic ownership trees.
This is the missing link for people wanting to do FP in Rust and even though this is an issue of standard library and not necessarily one of language, this will be a source of pain for people wanting to do FP in Rust, as FP means working with referential transparency, which begets immutability. This I think is worth mentioning, being the biggest road-block when wanting to adopt an FP style in any language - after all, any language that supports higher-order functions can be used for FP (or OOP) with varying levels of pain.
Again, as an outsider with a superficial understanding of Rust, it seems that Rust will make FP enjoyable in a language that doesn't need a garbage collector. But judging from articles and announcements made, Rust's primary objective to make concurrent programming safer isn't necessarily to make immutability effective, but rather to limit/control both shared reads and writes. And I can think of contexts in which you don't necessarily want that - after all, the shared reads of an immutable value are embarrassingly parallelizable, persistent data-structures working really well in say single-producer multiple-consumers scenarios. Plus immutable values are for having referential transparency and the common concurrency issues that we are commonly seeing are only a symptom. Truthfully, Rust must allow specialized algorithms and low level code, so I expect it to give the possibility of choosing your path instead of forcing a solution down your thrown.
But herein we are ending with a problem also exposed when working with C++. People have been doing FP in C++ with varying levels of success. But the problem with persistent data-structures that are doing structural sharing is one of memory management. It's much harder to implement persistent data-structures without relying on a garbage collector. LISPs that encourage an FP style, Ocaml, Haskell, SML, F#, Scala and all languages advertised as FP I can think about are garbage collected. Rust can use an optional garbage collector for "shared references". But that negates the biggest advantage when using Rust, the community is moving away from shared references and Rc/Arm touched in this article would be awful solutions to this problem.
Therefore I hope seeing progress in seeing a library of immutable data-structures that I could use in Rust or at least advice on how to deal with effectively immutable data-structures or something.
On the bright side - Rust's type system seems to be solid (yay generics, yay type-classes), which means it's just a matter of time before the libraries will get there.