9 ms·

What about Rust? Rust doesn’t go as in-depth as Haskell when it comes to modeling effects in the type system, but it still has a relatively complex type system

by y2bd 4y ago

What about Rust? Rust doesn’t go as in-depth as Haskell when it comes to modeling effects in the type system, but it still has a relatively complex type system on top of dealing with the borrow checker (which is almost as joked about as Monads at this point). Even with that difficulty, Rust seems to be a lot more successful than Haskell, and has existed for far less time. If it’s because Rust is still mostly imperative, then you could look to Clojure or even Scala—less complicated when it comes to types, but also (usually) much less imperative. Both I feel are more popular than Haskell.

caconym_ 4y ago
I was thinking about Rust a lot when I wrote this comment, actually. IMO, imperative vs. functional aside, Rust does suffer from a lot of the same learning curve issues people commonly pin on Haskell. Rust has plenty of libraries with weird, excessively "clever" APIs, weird experimental language features, a complicated metaprogramming facility, and so on. Personally, I have found lifetimes in Rust more annoying to deal with in semi-nontrivial situations than anything I ever encountered in Haskell, and it doesn't help that things that seem like they should work often don't. (I always figure that's the language telling me that I should use a different memory management strategy, and I generally follow its advice, but I digress.) This is very much my opinion, but I'd attribute Rust's success over Haskell to three main points: * Functional vs. imperative, skill curves. Rust is still vastly more familiar to most programmers at a first impression, and IMO it also has a lower skill floor. * Rust's tooling feels a lot more modern and streamlined. `cargo` is a joy to use. Maybe Haskell's ecosystem has improved, but back when I was actively using it, it was clearly inferior to Rust's. For me, this manifested mainly in significantly greater difficulties managing dependencies and reproducing builds. This stuff is a first-class priority for the Rust team, and it shows. * Somewhat related to the last point, Rust is "cool". It isn't burdened by decades of academic cruft; it just feels approachable, modern, and relevant in a way Haskell doesn't. The last two points aren't really Haskell's fault. I think the Rust team has done an absolutely top-tier job of making the language approachable and usable, obviously building on lessons of the past (including Haskell, Stack, cabal, haddock, etc.) and I'd almost say it's succeeded despite the essential nature of the Rust language itself.
- jpgvm 4y ago
  The difference is actually much more simple. Rust fills a gap, Haskell does not. Being purely functional seems like a massive win until you realize most of the real world benefit of that expresses itself as testability/correctness which can be obtained by other means. Lazy evaluation is actually a double edged sword so it's not a clear win either. Rust on the other hand is adding safety and correctness assurance specifically without or with very little runtime overhead while providing very predictable performance (both in runtime and space). You can sub Haskell out for Clojure/Scala/OCaml and arguably mixed paradigm languages like Kotlin/Rust/Swift and be fairly happy. However if the constraints of your problem call for Rust then your only other real options are to sacrifice correctness/data safety and use C/C++ instead. FWIW I think Haskell is awesome, this is just why I think we don't see it in "the real world' much.
  - ParetoOptimal 4y ago
    > Being purely functional seems like a massive win until you realize most of the real world benefit of that expresses itself as testability/correctness which can be obtained by other means. Is the end result reached by other means the same? Can you give an example of a competing approach in a non-pure language that gives one Haskell's advantages?
    - jpgvm 4y ago
      I don't think the result is the same but it is comparable. I would say using any language with a reasonable type system, say Kotlin w/property based testing gets you a result that while not as good as Haskell w/quickcheck is "good enough" for practical use in production software. There is maybe some niches where that wouldn't be the case like very high assurance software where instead of Haskell you might choose say ADA instead but I'm not really familiar with those domains.
      - ParetoOptimal 4y ago
        I actually think the construction method of and composition that aids code re-use very applicable to regular-degular workaday programming. Kotlin plus property testing gets you very far and the industry defaulting to that would be a huge improvement. I'll have to rewrite one of my Haskell projects in Kotlin and see if I feel anything is missing.

by y2bd 4y ago

caconym_ 4y ago

I was thinking about Rust a lot when I wrote this comment, actually. IMO, imperative vs. functional aside, Rust does suffer from a lot of the same learning curve issues people commonly pin on Haskell. Rust has plenty of libraries with weird, excessively "clever" APIs, weird experimental language features, a complicated metaprogramming facility, and so on. Personally, I have found lifetimes in Rust more annoying to deal with in semi-nontrivial situations than anything I ever encountered in Haskell, and it doesn't help that things that seem like they should work often don't. (I always figure that's the language telling me that I should use a different memory management strategy, and I generally follow its advice, but I digress.) This is very much my opinion, but I'd attribute Rust's success over Haskell to three main points: * Functional vs. imperative, skill curves. Rust is still vastly more familiar to most programmers at a first impression, and IMO it also has a lower skill floor. * Rust's tooling feels a lot more modern and streamlined. `cargo` is a joy to use. Maybe Haskell's ecosystem has improved, but back when I was actively using it, it was clearly inferior to Rust's. For me, this manifested mainly in significantly greater difficulties managing dependencies and reproducing builds. This stuff is a first-class priority for the Rust team, and it shows. * Somewhat related to the last point, Rust is "cool". It isn't burdened by decades of academic cruft; it just feels approachable, modern, and relevant in a way Haskell doesn't. The last two points aren't really Haskell's fault. I think the Rust team has done an absolutely top-tier job of making the language approachable and usable, obviously building on lessons of the past (including Haskell, Stack, cabal, haddock, etc.) and I'd almost say it's succeeded despite the essential nature of the Rust language itself.

jpgvm 4y ago
The difference is actually much more simple. Rust fills a gap, Haskell does not. Being purely functional seems like a massive win until you realize most of the real world benefit of that expresses itself as testability/correctness which can be obtained by other means. Lazy evaluation is actually a double edged sword so it's not a clear win either. Rust on the other hand is adding safety and correctness assurance specifically without or with very little runtime overhead while providing very predictable performance (both in runtime and space). You can sub Haskell out for Clojure/Scala/OCaml and arguably mixed paradigm languages like Kotlin/Rust/Swift and be fairly happy. However if the constraints of your problem call for Rust then your only other real options are to sacrifice correctness/data safety and use C/C++ instead. FWIW I think Haskell is awesome, this is just why I think we don't see it in "the real world' much.
- ParetoOptimal 4y ago
  > Being purely functional seems like a massive win until you realize most of the real world benefit of that expresses itself as testability/correctness which can be obtained by other means. Is the end result reached by other means the same? Can you give an example of a competing approach in a non-pure language that gives one Haskell's advantages?
  - jpgvm 4y ago
    I don't think the result is the same but it is comparable. I would say using any language with a reasonable type system, say Kotlin w/property based testing gets you a result that while not as good as Haskell w/quickcheck is "good enough" for practical use in production software. There is maybe some niches where that wouldn't be the case like very high assurance software where instead of Haskell you might choose say ADA instead but I'm not really familiar with those domains.
    - ParetoOptimal 4y ago
      I actually think the construction method of and composition that aids code re-use very applicable to regular-degular workaday programming. Kotlin plus property testing gets you very far and the industry defaulting to that would be a huge improvement. I'll have to rewrite one of my Haskell projects in Kotlin and see if I feel anything is missing.