4 ms·

Haskell is really good when: 1. You can afford the costs of a garbage-collected system. 2. Your collaborators know it or are eager to learn it. 3. You intend

Haskell is really good when: 1. You can afford the costs of a garbage-collected system. 2. Your collaborators know it or are eager to learn it. 3. You intend to maintain your system over an extended period of time while adding features. 4. You don't need close integration with the platform GUI. That last one isn't impossible to do in Haskell, but it's painful enough that it overrides the benefits in a lot of cases. What products niches does this leave? Servers and command-line tools, primarily, though there is room for GUI applications that use various cross-platform UI toolkits and games that build their entire UIs from scratch. (Yes, both of those exist. Even games. Unity uses C#, it's not like garbage collection is incompatible with games - it just has overhead you'll have to live with and work around.) Honestly, condition 2 above is the biggest limit. A lot of people who like to talk about judging things on their merits refuse to learn Haskell because it's not yet another shallow skin over the same programming concepts. My personal experience is that any time you think Ruby would be a good choice for a long-term project, Haskell is a far better option. It supports the same joy of green-field development but is less of a tarpit when the green field is 5 years behind you.

nicoburns 6y ago
Seems like you'd be better off using Rust for most of these. A lot of the same correctness benefits of Haskell, but a much more practical langauge with a more complete ecosystem of libraries.
- chowells 6y ago
  Rust? It's a fine C++ replacement. But it has nothing on Haskell in terms of practical expressiveness. I'll give it another look when it's capable of expressing an idea as simple as traverse.
  - _huayra_ 6y ago
    Amen. The real benefit of Haskell is not some hyper performance optimization (when you actually truly need C++ or Rust), but for business critical applications that need to perform fairly well and, most critically, need to not be filled with bugs as it continues to evolve. Whatever amount of money someone might lose by using Haskell compared to Rust or C++ (e.g. in hiring trainers to train your engineers, the overhead in terms of your PaaS bill due to GC or whatever else) is very small compared to the savings: - Compensating a customer for an SLA violation due to some inadequately tested code path that caused an outage - Wasted developer time trying to act like a Human Compiler (e.g. including a bunch of extra code to check type expectations and handle violations gracefully....at runtime) - Wasted developer time trying to understand the dynamic behavior of some code in a PR - Wasted developer time trying to understand old crufty parts of the codebase when you refactor Perhaps it's slow(er) to compile than you might like or not as optimal as C++, but unless you can afford to hire the absolute best Python / Ruby developers available and have some airtight culture of documentation and best practices, I would venture that it's better off to stake one's intellectual property on something that can survive employee churn without that knowledge walking out of the building.
    - nicoburns 6y ago
      Rust is also very good for correctness for a lot of the same reasons as Haskell.
      - valenterry 6y ago
        Rust is great and borrows many things from Haskell, but it's still very very far from Haskell.
  - pjmlp 6y ago
    Depends, I would certainly not pick Rust over C++ for graphics or GPGPU programming as I don't plan to be one doing the ground work to build something that has the industry acceptance of SYSCL, CUDA, Qt, COM/UWP, MSL. Ironically C++ is closer to Haskell in regards to expressiveness.
  - nix23 6y ago
    Bit sad that everyone forgets OCaml when comparing Haskell.
    - grzm 6y ago
      Rather than merely lamenting that no one's mentioned OCaml, how about providing something specific about OCaml you think is relevant to contribute to the discussion?
      - nix23 6y ago
        >Rather than merely lamenting Why not read for yourself then? https://ocaml.org/ https://ocaml.org/
      - HelloNurse 6y ago
        For example, pointers about how OCaml compares to Haskell weak spots: - Basic features (e.g. records, strings, portability) - Undocumented, fragmented and/or half baked libraries - Bizarre and inconvenient "advanced" syntax - Extravagant memory usage
    - chowells 6y ago
      OCaml also can't implement traverse, so....
- pjmlp 6y ago
  Rust is only an option if one needs deployment scenarios where having a GC is a not an option. For everything else you are better off with a language that supports automatic memory management, and now Haskell is even supporting linear types anyway.
  - nicoburns 6y ago
    That depends on whether you find having to manage memory more of an impediment, or whether you find not having easy access to imperative constructs more of an impediment.
    - pjmlp 6y ago
      People keep forgetting that GC enabled languages like F#, Haskell, D, C#, OCaml, also provide mechanisms to fine tune memory allocation, its location on the stack and global memory segments besides GC heap, and even native heap. Additionally some of them, like Haskell being discussed here, are also extending their type systems to provide Rust like guarantees for resource management, for the 1% uses cases where it really matters. As for my short experiments doing graphics programming with Rust, it is naturally an impediment, that proves the point that Rust place is as systems programming language filling the same role as C++ on Android, UWP or Apple platforms, the low level drivers, compiler toolchain, windows system compositor.
      - nicoburns 6y ago
        It definitely depends on your domain. For web servers I've found there's little to no overhead for doing it in Rust.
        pjmlp 6y ago
        It is still something that everyone using the language have to deal with, regardless how little it is. Whereas with automatic memory management languages, if and only when it becomes an hurdle, the performance expert can pick up a profiler and only optimise what is required. Using .NET as example, then one can think about struct vs class, new vs stackalloc vs Marshal.AllocHGlobal, direct arrays vs Span<>. Or based on experience, already pick the right data structure and memory location right from the start.

nicoburns 6y ago

Seems like you'd be better off using Rust for most of these. A lot of the same correctness benefits of Haskell, but a much more practical langauge with a more complete ecosystem of libraries.

chowells 6y ago
Rust? It's a fine C++ replacement. But it has nothing on Haskell in terms of practical expressiveness. I'll give it another look when it's capable of expressing an idea as simple as traverse.
- _huayra_ 6y ago
  Amen. The real benefit of Haskell is not some hyper performance optimization (when you actually truly need C++ or Rust), but for business critical applications that need to perform fairly well and, most critically, need to not be filled with bugs as it continues to evolve. Whatever amount of money someone might lose by using Haskell compared to Rust or C++ (e.g. in hiring trainers to train your engineers, the overhead in terms of your PaaS bill due to GC or whatever else) is very small compared to the savings: - Compensating a customer for an SLA violation due to some inadequately tested code path that caused an outage - Wasted developer time trying to act like a Human Compiler (e.g. including a bunch of extra code to check type expectations and handle violations gracefully....at runtime) - Wasted developer time trying to understand the dynamic behavior of some code in a PR - Wasted developer time trying to understand old crufty parts of the codebase when you refactor Perhaps it's slow(er) to compile than you might like or not as optimal as C++, but unless you can afford to hire the absolute best Python / Ruby developers available and have some airtight culture of documentation and best practices, I would venture that it's better off to stake one's intellectual property on something that can survive employee churn without that knowledge walking out of the building.
  - nicoburns 6y ago
    Rust is also very good for correctness for a lot of the same reasons as Haskell.
    - valenterry 6y ago
      Rust is great and borrows many things from Haskell, but it's still very very far from Haskell.
- pjmlp 6y ago
  Depends, I would certainly not pick Rust over C++ for graphics or GPGPU programming as I don't plan to be one doing the ground work to build something that has the industry acceptance of SYSCL, CUDA, Qt, COM/UWP, MSL. Ironically C++ is closer to Haskell in regards to expressiveness.
- nix23 6y ago
  Bit sad that everyone forgets OCaml when comparing Haskell.
  - grzm 6y ago
    Rather than merely lamenting that no one's mentioned OCaml, how about providing something specific about OCaml you think is relevant to contribute to the discussion?
    - nix23 6y ago
      >Rather than merely lamenting Why not read for yourself then? https://ocaml.org/ https://ocaml.org/
    - HelloNurse 6y ago
      For example, pointers about how OCaml compares to Haskell weak spots: - Basic features (e.g. records, strings, portability) - Undocumented, fragmented and/or half baked libraries - Bizarre and inconvenient "advanced" syntax - Extravagant memory usage
  - chowells 6y ago
    OCaml also can't implement traverse, so....
pjmlp 6y ago
Rust is only an option if one needs deployment scenarios where having a GC is a not an option. For everything else you are better off with a language that supports automatic memory management, and now Haskell is even supporting linear types anyway.
- nicoburns 6y ago
  That depends on whether you find having to manage memory more of an impediment, or whether you find not having easy access to imperative constructs more of an impediment.
  - pjmlp 6y ago
    People keep forgetting that GC enabled languages like F#, Haskell, D, C#, OCaml, also provide mechanisms to fine tune memory allocation, its location on the stack and global memory segments besides GC heap, and even native heap. Additionally some of them, like Haskell being discussed here, are also extending their type systems to provide Rust like guarantees for resource management, for the 1% uses cases where it really matters. As for my short experiments doing graphics programming with Rust, it is naturally an impediment, that proves the point that Rust place is as systems programming language filling the same role as C++ on Android, UWP or Apple platforms, the low level drivers, compiler toolchain, windows system compositor.
    - nicoburns 6y ago
      It definitely depends on your domain. For web servers I've found there's little to no overhead for doing it in Rust.
      - pjmlp 6y ago
        It is still something that everyone using the language have to deal with, regardless how little it is. Whereas with automatic memory management languages, if and only when it becomes an hurdle, the performance expert can pick up a profiler and only optimise what is required. Using .NET as example, then one can think about struct vs class, new vs stackalloc vs Marshal.AllocHGlobal, direct arrays vs Span<>. Or based on experience, already pick the right data structure and memory location right from the start.