Rust for functional programmers

Sounds as if there are some bits of the article that could be tightened up or corrected, but I found the article very helpful. It's been about 10 years since I've coded in a C-style language (Java, C#, C++), but I'm very familiar with significant-whitespace languages (Python, Haskell, Coffeescript). The C-style-ish-ness of Rust has colored my perception of the language: the features sound great... but it looks like C? Admittedly, an unfortunately shallow perspective, but we've all got a lot of ground to cover and the view from 10km is necessarily incomplete.

The article's side-by-side examples really opened my eyes. I understand that Rust doesn't implement all of the functionality of Haskell, but it's comforting to see analogous functionality. So Traits aren't Type Classes; but as a beginner in Rust and as a first-order approximation, I can hear sorta-Type-Classes when I see Traits. That'll get me past the first steps, then I can dig into the detail of Traits.

I would suggest the author include a section on Side Effects since that's a big talking point around functional languages. Some allow them pretty freely (Ocaml) and some don't (Haskell). The only place I really see mention of this Big Deal is a little header to a code comparison saying "Recursion with side effects:".

The stuff about boxing, Rc and Gc is simply wrong. For example:

`box foo` is Box<T>, the old ~T, nothing to do with Gc or Rc.

Gc is not at all clever and does not do cycle collection.

There are quite a number of other wrong or slightly wrong things about Rust, and a total ignoring of many Rust conventions.

It's funny, this article is dripping with attitude about how Rust will bring poor naive C programmers who are caught in the 70s into modern language design.

You could write just the same kind of article about how Rust will bring out-of-touch theorists into modern software engineering where you actually need a C-level of performance and predictability. And then show examples of all the same "for" loops with mutable variables that you're used to writing in C have direct analogs in Rust.

But both bits of snark would miss the point, which is: Rust is awesome precisely because it merges these two schools of thought into something that preserves the advantages of both.

As a Haskell dev about to get into Rust (and appreciates occasional parallels to OCaml) I found this very insightful. I especially like the attention given to the tables of language literals.

Not that it takes away from the purpose of the post but I couldn't help but see some issues in the Haskell code.

The code under "Recursive data structures" is not valid, top-level code in a Haskell source-file isn't evaluated like in Ocaml, I'd remove the "let" keywords and put "main = " in front of the putStrLn function (which is also misspelled).

As others have mentioned, the ADT example is wrong, you need to use "data" instead of "type", and the convention for the optional type in Haskell is "data Maybe a = Nothing | Just".

  hello x =
      test x

This might be intentional, but it's very unconventional to put a newline after the equality sign in that short function.

  if v /= 1 then collatz v
            else return ()

This is better written as:

  when (v /= 1) (collatz v)

and compares better with the Rust and OCaml code.

This is interesting, although it contains a few misconceptions/mistakes/typos.

http://www.reddit.com/r/rust/comments/2al19j/rust_for_functi...

I've been very hungry for some rust doc ... as everyone knows, past some good introductory stuff, a lot of detail is not documented yet. I'd vote you up +100 if I could. Thanks for this.

Nice article! This Haskell is incorrect, though:

    {- Haskell -}
    type Maybe a =
        None
      | Just a

    {- x : Maybe t -}
    case x of
       None -> False
       Some _ -> True

In that snippet, `type` needs to be `data`. Also the canonical constructors are `Nothing` and `Just` (but that doesn't have to do with correctness :))

There are also a few times where you use a single colon for a type annotation in Haskell, instead of a double colon.

Also, I disagree with this:

> Rust's “traits” are analogous to Haskell's type classes.

> The main difference with Haskell is that traits only intervene for expressions with dot notation, ie. of the form a.foo(b).

That's more of a syntactic distinction; the difference at a semantic level is much bigger: Haskell type classes extend to higher-order types. For example, Functor and Monad rely on a type with kind `* -> *`, and it can get more complex than that, for example with monad transformer classes (like State and Error).

Also, an important difference is that Rust traits can be used as Java-style interfaces; for example, you can have a list of objects of different types, but that all implement `Show`.

I really liked this article! The side-by-sides were very well done. Thanks!

What the for loop actually expands to is much easier to read.

    [<label>] for <pat> in <iterator expression> { ... }

    let __iterator = &mut <iterator expression>;
    <label> loop {
        match __iterator.next() {
            None => break,
            Some(<pat>) => { ... }
        }
    }

I like a lot things about Rust. But on the downside it's syntax feels a little too much like C for comfort. Working with pointers to this extent has never been my idea of productive programming. In addition the whole Box, Rc and Arc business feels almost like a kludge. Are they part of the language or just some add on? The syntax makes it feel very much like the later.

It might be useful, from a language-evangelism point of view, to show how much of this Go doesn't do. This isn't to criticize Go--but I have gotten the impression (perhaps wrongly) that these languages are competitors.

There's a missing semicolon in the Rust collatz code, let .. match { ... } ; <- here.

The Rust loop version of collatz is also missing a semicolon and missing a ! in println!.

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.