My point above about Go (but put somewhat trollishly I admit) was that if rust forsakes the things which make functional programming great, what about it is compelling? I was under the impression that it was supposed to be the functional systems programming alternative.

Well, there are a couple compelling points about Rust:

- deterministic memory management

- actual generics. :P

- an advanced type system (vs. java/c++)

- design choices taken towards efficiency

- default-immutable memory

I think your impression is mistaken. While functional style programming is supported, I have never gotten the impression that it's the main goal: http://static.rust-lang.org/doc/tutorial.html#introduction

> I was under the impression that it was supposed to be the functional systems programming alternative.

The elevator pitch is "Speed of C++, safety of ML, concurrency of Erlang."

Note that this doesn't say "concision of ML", although clearly they're aiming for that wherever possible.

(Is concision really what you lose when you need explicit looping constructs? Maybe "abstraction capability"?)

Wouldn't self/co-recursion be a safety of ML feature? Otherwise wouldn't you need mutation to do anything useful without worrying about your stack?

I think you're mixing up tail recursion with general recursion. Rust absolutely supports recursion: the implementation uses segmented stacks to allow for stacks to grow dynamically. Tail call support is about not having the stack grow but only in the subset of recursive calls that are in tail position.

So support for tail calls is not about safety but expressiveness, and Rust chooses to express iterative algorithms through other means, such as the iteration protocol that's built on top of higher-order functions.

EDIT: Maybe I'm misreading you and you only mean the imperative nature of loops forces you to use mutation. Rust does not eschew mutation altogether. Even as a functional programmer myself, I'd argue pretty emphatically that mutation, particularly of local variables, is not a grave safety concern.

From a certain perspective, yes. You're confusing the tool with its purpose.

What do you mean? Combinators are great (even if implemented imperatively) until you really care about performance and isn't that what this rust discussion is all about.

Did you mean something other than combinators?

I mean that 'safety' means a wide variety of things, and you're conflating the PLT feature with the more general reason why that feature was needed.

For example, above, you mention how TCO lets you use first-class functions to help you eliminate mutability. It's the elimination of mutability that's the safety here. Rust allows you to eliminate mutability through other means.

Their specific performance-related target is to have predictable, low worst-case latencies. In throughput-style loads, they might well lose to Haskell most of the time.

For some use cases (games, web browsers, etc) the first goal is much more important than the second.

Coming from haskell, I just like the fact that rust has a decent record syntax built in :)