Hacker News Reader

Comment by zerr | Hacker News Reader

I've heard from some long-time Haskellers that there is no point in continuing using the language after the advent of Rust.

EDIT: I should have clarified I guess - interested to hear the opposite arguments (as a neutral (C++) person :)).

View on HN

For me it's been the opposite. Rust was the first programming language I learned back in 2014, and it's what I've mainly been using until recently. Rust is still my go-to for situations where performance is key, but my most used language today has become Haskell.

Rust is very nice, but when you've used it for long enough you start noticing the warts. I especially miss Higher Kinded Types from Haskell, and I'm constantly reminded of the lack of Functor and Monad etc. At some point I simply realized that for most applications, the generally lower performance of Haskell and the GC is really not a problem at all. I mean, it's not like it's Python slow—it's just a bit slower than C/Rust. The more advanced type system of Haskell is just so nice, that I feel it's worth it.

As a Rustacean, I find that silly. There's a lot to love about Haskell.

I'd be interested in hearing from your Haskellers what it is about Rust that renders Haskell obsolete. As it stands, I can only construct straw men, and I'm not really willing to do that.

From the pure language perspective (i.e. batteries aside), what do you miss in Rust from Haskell?

I've used both extensively, even on some similar projects. Biggest thing I've noticed with Rust is that—often by necessity—it's hard to design abstractions that don't leak implementation details. That's a fundamental property of how Rust uses its types to manage resources, and it can definitely pay off for some kinds of code with particular performance requirements. In practice, though, it also makes it much harder to write reusable abstractions, especially with anything involving first-class functions and polymorphism.

The upshot is that the two languages feel very different, encourage totally different programming patterns and give you different high-level trade-offs. They're far more complementary than substitutable, and I expect my future projects will mix and match both.

Everyone else pretty much said it for me. To elaborate more personally: the distilled expression of pure functions as _the_ basic entity of modular engineering is such a huge selling point for me. Lazy evaluation is also surprisingly valuable in this vein, because I can compose components -- pass the output of a component to the input of another -- with the assurance that I'll only pay for that computation if it's actually requested.

I do deeply appreciate Rust in how it supports serious functional programming idioms without requiring a GC. The value of immutable-by-default and single-ownership semantics have been infectious far beyond my direct use of Rust. But those very same features of Rust also make the pure function just a little more clunky in that environment.

Oh, and being literally unable to perform I/O (or any other computational effect) outside of the right context is such a clear win for me. Very few languages, even in the functional world, have such a strict separation. The architectural and mental benefits are outstanding.

Some concepts take on a surprisingly simple existence in Haskell. I recently discovered the Yoneda and codensity transformations, as so frequently discussed in Haskell... in the context of a Visitor pattern on a tree structure in Java. Visitors are literally Yonada-ified sum types, and I could only make that connection (and understand the ramifications and benefits) after seeing how it naturally arises in both languages.

>Very few languages, even in the functional world, have such a strict separation.

It's catching on. Nim has the noSideEffect pragma (enabled by default if a function is defined with "func" rather than "proc"), and D has a "pure" annotation. Both are compiler-checked.

Lightweight syntax and HKTs, for me.

edit: and automatic currying

Functional programming. Meaning solving large swathes of a problem with (->) alone. Sadly a lack of GC does have downsides in this respect.

Controlled side effects

Ability to do more-expressive programming. GC is one thing that's required for that.

Rust doesn't even have higher-kinded types, yet alone kind polymorphism. That means no proper do notation, so look at the complete mess of macro-based syntaxes you have for things like error propagation, async or transactions. Things like recursion-schemes are impossible, and the borrow checker is kind of ad-hoc, meaning the control flow keywords are special cases and you often can't do what should be a very simple substitution when you want to add an effect (e.g. if -> ifM is not possible because if is not an expression and the borrow checker wouldn't be able to handle it if it was).

Rust may be the language that has finally dragged mainstream programming kicking and screaming into the 1970s (it's more or less the equal of Standard ML). It still has a ways to go to catch up with Haskell.

I've heard from some long time pear consumers that there is no point in continuing to eat them following the discovery of the apple.

Reply on news.ycombinator.com