5 ms·

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 Ha

• zerr 6y ago
  From the pure language perspective (i.e. batteries aside), what do you miss in Rust from Haskell?
  • JoelMcCracken 6y ago
    Controlled side effects
  • whateveracct 6y ago
    Functional programming. Meaning solving large swathes of a problem with (->) alone. Sadly a lack of GC does have downsides in this respect.
  • jolux 6y ago
    Lightweight syntax and HKTs, for me. edit: and automatic currying
  • cies 6y ago
    Ability to do more-expressive programming. GC is one thing that's required for that.
  • Twisol 6y ago
    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.
    • logicchains 6y ago
      >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.
  • tikhonj 6y ago
    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.