Raphael Poss

As a scientific programmer interested in functional-flavoured (ie undogmatic) languages, I would do Rust immediately if it had a REPL. Dying to dump Python. This post is very convincing on Rust's design decisions:

http://science.raphael.poss.name/rust-for-functional-programmers.html

This post was a total revelation to me, even if I assume it's well known in the community, because it is very credible on the Sophie's Choice issue of mathematical purity versus acknowledgement of the reality of the instruction pointer-based imperative machine that exists underneath.

I've looked at other languages that "do" multiprocessing recently. Go is great, but it's essentially about getting large teams of variable-skill people to work together well. It's not an inspiring language, whereas Rust clearly is. Erlang (via Elixir) is very interesting, but the actor model will never be as performant in reality as the shared memory architecture. Julia is just a modern interpretation of matlab. A number of the JVM languages are great, but the "culture" of that ecosystem will always be corporate.

This is why I believe the science crowd could really gravitate to Rust, because it may have the ability, like the functional crowd, to satisfy the "search for beauty" aspect which motivates many academics, scientists, and indeed, programmers, all the while staying just the right side of pragmatism. And clearly targeting "where the puck is going" on massively multicore hardware.

The trial-and-error…

I think the situation of your [1] is that Rust has ended up close enough to C++ that it's useful and meaningful to provide a translation guide between concepts, to help C++ programmers get up to speed more easily; it's certainly not a design document or anything like that. Maybe I'm missing your point. (As I said elsewhere, C++ has had a lot of experience in this space, and so has a lot of good ideas, Rust is not ashamed to borrow them.)

On that note, would you interpret [a] as meaning Rust is trying to be a functional language? The reality is more plagiaristic: functional language have nice features and so Rust borrows some of them. (In my mind the correct interpretation of both documents would be: Rust is a mesh of various languages with enough similarity to many for translation guides to be helpful.)

There has been syntactic decisions tilting towards C++/Java/C# programmers (like the <> for generics), but as far as I can remember those sort of decisions are all minor in terms of semantics. For the most part the actual semantic behaviours are considered in terms of "does Rust need this" rather than "will this move us more towards C++" (even if the feature was inspired by C++).

[a]: http://science.raphael.poss.name/rust-for-functional-programmers.html

I spent around 30 minutes reading "Rust for functional programmers" [1] to get overall perspective and then around 3 hours more reading selected chapters from "The Book" [2] about borrowing, lifetimes etc.

Then I managed to write a simple program which reads a password from stdin, applies scrypt KDF to it and prints the result in hex encoding. It took me less than 2 hours. Mostly I just tried to do something, and when it didn't work, I'd find a solution for my problem on stackoverflow or r/rust. Compiler error messages were also quite helpful.

So I managed to write a useful (for me) simple CLI application in 1 day. The next day I added option processing (salt, scrypt parameters), split the code into functions etc. I didn't encounter any problem which I couldn't solve in under 1 hour. The biggest struggle was trying to return a reference to local variable from function, and it was covered in [3].

TLDR: don't try to master the language, just give it a try for a few days, writing a simple program.

[1] http://science.raphael.poss.name/rust-for-functional-programmers.html

[2] https://doc.rust-lang.org/book/

[3] https://bryce.fisher-fleig.org/blog/strategies-for-returning-references-in-rust/index.html

> It seems like everything I know about structuring a program goes out the window when borrowing comes into the picture.

Try to avoid structured programming and mutable state where possible. Apply functional programming idioms and use immutable data structures if you can. Rust adopts many features from functional programming languages: http://science.raphael.poss.name/rust-for-functional-programmers.html

Borrow checker will interfere only when you are trying to manage mutable state that is hard to reason about. If you absolutely must keep some mutable data structure around, you can fall back to unsafe code. There is nothing wrong with it, but make sure to put all unsafe code into separate module and provide only safe interface, that is absolutely unbreakable no matter how you use its public API.

Make sure you know about this module: https://doc.rust-lang.org/std/mem/ It is nearly impossible to create complex data structures without it, even linked list implementation requires it. Learn to use replace, swap and .take(). These functions provide great example of a safe API for unsafe operations.

> and you wouldn't use it in your code

Speak for yourself. I don't see any value in not using a tool when it's available and seems to do the job:

http://science.raphael.poss.name/haskell-for-ocaml-programmers.html#print-debugging

Personally I don't believe in 100% pure FP, it's both a pain in the ass and doesn't really give you more than 85% FP already would. Actually, most of the FP world seems to agree: out of many Lisps, Scala, OCaml, SML, F#, Erlang/Elixir etc. only Haskell is that hell-bent on purity. Even things like PureScript are more pragmatic than Haskell in this regard.

Here's a great talk on getting what's best from FP without also taking all the problems: http://www.infoq.com/presentations/functional-pros-cons

> I'd love to hear the argument that says that it is...

http://science.raphael.poss.name/rust-for-functional-programmers.html

I personally think Rust isn't functional, but rather multi-paradigm with a strong functional influence. But if you were to add TCO and a few other features, I think Rust would be a full-blown functional language, so it may get there yet.

In any case, it's useless arguing over (should have known better than say anything), so this will be my last word on the issue.