Hacker News Reader

Comment by andywood | Hacker News Reader

Now, as a follow-up: is anything holding back Rust?

Anyone who understands Rust's good points (and there are many) is probably already using Haskell. What compelling advantage does Rust have over Haskell to justify the cost of switching (and, more importantly, the cost of losing higher-kinded types, and of adding macros)? Manual memory management is unlikely to be enough.

I see. I was thinking generally about tools / libs / ecosystem, and platform presence. I actually didn't realize Haskell was already so established.

It is established among a very competent, smart, and vocal community. It is not established as a language heavily used in industry or most open source projects by any means.

I meant less that lots of people use Haskell and more that most C++ folks aren't interested in changing languages.

There's a ton of people who aren't using Haskell and never will. It is a great language, but it isn't a language that will ever be really popular.

Rust bridges the gap between industry C++ programmers with the ideas of Haskell. Sure you might not see a lot of codebases migrated from Haskell to Rust (not that there are a massive amount of anyway), but you will likely see C++ codebases migrated over to it, and Haskell programmers that want their library to be widely used may start greenfied projects in Rust instead of Haskell.

You are looking at it from a Haskell -> Rust conversion cycle, when that isn't really important from either a numbers standpoint or how Rust is positioning itself.

Let me put it this way then: why would someone using C++ who will be willing to migrate to Rust in the future not be willing to migrate to Haskell now?

Many of the advantages and disadvantages are the same: different syntax, weird sigils, an emphasis on immutability, a much more restrictive compiler, a strong type system, a new way of thinking about your programs. And it will take Rust a long time to reach the maturity and library ecosystem that Haskell currently has.

One might catch a few people who absolutely need manual memory management, I guess, but my experience is that this is often an excuse and those who are seriously interested in using another language find ways around the problem. For OS kernels and the like Rust has an advantage, but again that's a tiny niche. Rust's C FFI might be a bit better, but honestly Haskell's is rather good; I can't see that making the difference. And if you find the safety or the type system compelling, surely you've already moved beyond C++.

I'd like to be wrong - I'd like to see C++ programs moving into better languages. But I think a need for manual memory management is very rarely the real reason people are still using C++ - and if it's not that, what can Rust offer that wasn't already available?

The people sticking to C++ aren't using it for the sheer joy of manual memory management, they're using it because they either require or enjoy the ability to exert predictable control over programs in terms of both execution speed and memory usage. Haskell, being a lazily-evaluated garbage-collected language, offers little to these people.

Rust has emphatically never been "Haskell with manual memory management". That conception is entirely incorrect, typeclasses or no. If you must frame Rust in terms of prior languages, consider it to be an ML with an extreme focus on zero-cost abstractions and pervasive, memory-safe concurrency.

Many of those C++ developers are using it, because C and C++ are the only languages with native compilation toolchains that all OS vendors have on their SDKs.

When will Rust be pushed by an OS vendor?

Predictable performance.

That seems to be the main selling point for Rust, anyhow. Zero cost abstractions, predictable data sizes, well defined memory scopes, etc.

Anyone who understands Rust's good points wouldn't write a comment like yours. Rust's goal is to be a systems language that allows one to write programs with native performance (equivalent to C's) without sacrificing the safety of higher-level languages by leveraging an advanced type system. Haskell is an extremely poor candidate for that niche.

It is entirely possible to write native-performance (better than C++, and soft-realtime at the same time) programs in Haskell; I've seen it done in a professional environment.

Reply on news.ycombinator.com