Hacker News Reader

Comment by Rickasaurus | Hacker News Reader

Sounds mostly like a pile of empty words to me. Usable and pragmatic are purely contextual. Is rust faster than Haskell?

View on HN

>Sounds mostly like a pile of empty words to me.

All words are empty until we put meaning on them. Go and read what they are trying to achieve and how, and then they won't be empty anymore.

>Usable and pragmatic are purely contextual. Is rust faster than Haskell?

It's not highly optimized yet, as it's in pre-alpha stage. But it's goal is to be faster than Haskell, and close to C/C++/ADA speed.

Usable and pragmatic means that it should work for their goals, which are very real and tangible themselves: to use it as a compiled language to create a fast, parallel and secure web browser engine.

They don't want to pile on academic concept and programming features or compiler tricks just to be "cool", "interesting", or "cutting edge". They don't even care if they would be "nice to have". They care about: what helps their goals, and what can be implemented without overcomplicating things.

If Rust cannot become a language in which it's able to write a fast (faster than the currently available), parallel (more parallel than the currently available) and safe (safer than the currently available) browser engine, then it would have failed on its targets.

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 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."

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?

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.

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.

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"?)

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

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 :)

They eventually want to be competitive against C++ code and it seems they won't support TCO as that would harm their performance target.

The thing is that most C and C++ compilers actually do TCO when applying -O2 or similar, if they see the possibility to do so.

As I stated above, the C and C++ optimization is only sibling call optimization, which Rust does too.

Ah ok, I missed that, thanks for pointing it out.

Not having TCO might lead to a much bigger problem than not hitting a performance target for large numbers of loop iterations. I'd rather have a program that is slightly slower and that works correctly for all input than one that has a built in - but invisible and hard to test for - hard limit.

I assume you mean that without TCO the stack might overflow for certain inputs and it is easy to miss those cases during testing.

Is that actually a real problem? I never hear C/C++/Java/Python/Ruby/Javascript/D/Go/Clojure programmers complain about such bugs. On a Linux/Windows/OS X system the stacks are big enough to practically never hit such bugs. Whenever I get a stack overflow, I coded an infinite loop, which is actually easier to find without TCO, because the program is terminated.

C/C++ etc don't have that problem because they have loops.

TCO is a way to turn a recursion into a loop. If for every situation where you would elegantly use recursion you'd end up with real recursion and all its overhead you'd indeed end up overflowing the stack. For a C/C++ etc program it would not matter whether your loop iterator would be 10 or 10,000,000,000, the program would just run a little slower. The rust/clojure program (coded up without knowledge of the underlying mechanisms, so 'naively') would likely run out of memory. With TCO such a naive implementation would run just fine. 10,000,000,000 is merely large, not infinite and should all things otherwise being equal not come with a huge memory penalty if all you're doing is writing elegant code in the most applicable idiom for a certain language.

I can't speak for Clojure, but the idiomatic Rust code that I've seen does tend toward C-style iteration (though that iteration is discreetly accomplished via closures and higher-order functions) rather than Lisp-style recursion. So I wouldn't expect recursive memory exhaustion to be a common concern in idiomatic Rust, though that's obviously no consolation if you were hoping to code in a recursive style.

Though perhaps you'll be happy to hear that Rust stacks are growable (Go-style) rather than fixed, so stacks are typically small and running out of stack is (afaict) theoretically less of a concern than in C/C++.

The most applicable idiom for Rust is to use looping with higher-order functions. Rust code doesn't really favor recursion.

Yes, but that may very well be because it does not do TCO... What's idiomatic in a language is usually the result of how efficiently that language implements certain constructs.

Even if we implemented TCO, I doubt it would be idiomatic because destructors reduce the number of tail call positions so dramatically.

Right, because any destructor would break your ability to do TCO assuming that it runs before the tail call... So as soon as you use an object mechanism that will invoke a destructor at some point your ability to use TCO is gone.

Interesting, isn't there a possible transformation where you would be able to move the constructor/destructor pairs out of the generated loop construct without breaking the function?

After all a tail call is just a fancy go-to under the hood.

Reply on news.ycombinator.com