As a Haskell programmer, “OCaml has the nicest type features” hurts just a little bit.
I sometimes teach a course in OCaml. The students who are very engaged inevitably ask me about Haskell, I encourage them to try it, and then they spend the rest of the semester wondering why the course is taught in OCaml. Bizarre how different that is from when colleagues in industry want to try Haskell.
Haskell is not good for systems programming which sums up about 60-70% of that post. Laziness is lovely in theory but many industry uses of Haskell use stricthaskell for all or most of their code, so I certainly agree with that part too.
Their largest complaint about using Haskell for small non-systems programs seems to be the mental overhead induced by laziness. But for me, for small programs where performance isn’t a huge concern (think Advent of code or a script for daily life) laziness reduces my mental overhead. I think that author is just especially concerned about having a deep understanding of their programs’ performance because of their systems background. I worry about performance when it becomes relevant. Debugging Haskell performance issues is certainly harder than strict languages but still totally doable.
The lack of type classes or other form of ergonomic overloading in OCaml is easily the single “feature” most responsible for the language never taking off.
As a Haskell programmer, “OCaml has the nicest type features” hurts just a little bit.
I sometimes teach a course in OCaml. The students who are very engaged inevitably ask me about Haskell, I encourage them to try it, and then they spend the rest of the semester wondering why the course is taught in OCaml. Bizarre how different that is from when colleagues in industry want to try Haskell.
What are your thoughts on this comparison? https://github.com/sidkshatriya/me/blob/master/007-My-Thoughts-on-OCaml-vs-Haskell-Rust-2023.md
Largely reasonable?
Haskell is not good for systems programming which sums up about 60-70% of that post. Laziness is lovely in theory but many industry uses of Haskell use stricthaskell for all or most of their code, so I certainly agree with that part too.
Their largest complaint about using Haskell for small non-systems programs seems to be the mental overhead induced by laziness. But for me, for small programs where performance isn’t a huge concern (think Advent of code or a script for daily life) laziness reduces my mental overhead. I think that author is just especially concerned about having a deep understanding of their programs’ performance because of their systems background. I worry about performance when it becomes relevant. Debugging Haskell performance issues is certainly harder than strict languages but still totally doable.
The lack of type classes or other form of ergonomic overloading in OCaml is easily the single “feature” most responsible for the language never taking off.