When Rust is safer than Haskell | Hacker News Reader

When Rust is safer than Haskell

fpcomplete.com

61 pointssidcool15 comments

As an almost two decade Haskeller who really wants to try Rust in a performance and security sensitive production context, I really appreciated this article. However, it might have actually pushed me more toward Haskell. I have decades of experience in C-derived languages and the syntax is just not my favorite, compared to Haskell and LISPs.

Of course, given the 3,619,661 compiler extensions in GHC, whats another that would enable this sort of lifetime/reference tracking (and endless chasing of type errors that all Haskellers are used to anyway) functionality to be pushed into the type system? I almost cannot imagine it has not been done.

Great article!

Figuring out lifetimes in the face of Haskell's laziness sounds like a daunting prospect to me.

Ultimately, there doesn't have to be a language to rule them all. Rust does things well that Haskell doesn't, and vice versa, and that's just fine.

Oh, for sure. Very focused languages are great.

Haskell (well, GHC) just seems to be a great resource for trying language features out. No argument that laziness could be an issue, but IO generally has to resolve thunks anyway to occur so it may not be an insurmountable one. Note that I do not know particularly much about GHC internals.

Not really, as the point of affine types is that this is pushed into the type system. It has the semantics “if a thing is produced, it is consumed at most once.” I don’t see how this is any more difficult than, or really any different from regular Haskell programming.

> course, given the 3,619,661 compiler extensions in GHC, whats another that would enable this sort of lifetime/reference tracking (and endless chasing of type errors that all Haskellers are used to anyway) functionality to be pushed into the type system?

Rust-style ownership semantics exert strong design pressure on libraries, including the standard library. Rust's ecosystem has evolved under that pressure; Haskell's has not. I have no doubt at all that Haskell could be extended with affine types (never go in against a Haskeller when a conference paper is on the line!), but once you'd done that, you wouldn't be able to use any existing libraries.

Which, given the state of the Haskell ecosystem, might be a bit of a relief.

This is also the reason why bolting lifetimes on to C++ is not really feasible while still being able to call the resulting language C++.

They are being bolted on static analysis tools.

So yeah, optional tooling quite often doesn't get used and is imperfect.

On the other hand, many will not move if they can get 80% there, while keeping their tooling and libraries.

Obviously we disagree about whether any attempts to add lifetime analysis to C++ gets anywhere near 80% of what Rust can provide.

Actually no, Linear Haskell works in a fully backwards compatible way with existing libraries. I suggest checking it out.

What would you suggest i read? I have got the 'Retrofitting Linear Types', and a quick scan suggests it doesn't give concrete examples of that backwards compatibility (although it probably follows from the proofs, which i have not digested yet!). Is there something more practical?

There's a bit more said about it here:

https://arxiv.org/pdf/1710.09756.pdf

Nothing. Linear types are being added to GHC and could be used to implement this feature. But libraries would need to be upgraded to offer them.

I think the most interesting this here is the multiple steps of 'fighting with the compiler', being illustrated on a case we know up front is actually a bad idea. Most of the time we need to go through all those steps to realize that oh, this actually didn't make much sense in the first place. Which doesn't always feel that rewarding...

In my experience a while back when writing socket / IO code, I thought Rust was safer because standard library functions in Haskell (and other languages I experimented around with) could throw unchecked exceptions/errors.

Never mind about data races :).

Gorgeous article. And it shows that regardless how strong rust is, it does not hide the complexity of the subject. Very nice.

Reply on news.ycombinator.com