OCaml's typing system is in my eyes unbeatable. Still considering making a transpiler from it to Rust and Elixir but I'm grossly unqualified to write compilers. :(
Haskell though, I couldn't grok it. Seemed to introduce a lot of tension for very basic topics -- like strings -- and it lost me.
If you know OCaml it's within reach. The advantage is that you have better lazy data structures with GHC.
How does the OCaml type system compare with Haskell's though?
Truthfully though, both languages have similar pains. You can do one thing in 10 different ways in both, for example, which isn't tempting.
But OCaml seems more terse, and its compiler is lightning-fast, so that tipped the scales for me.
In Haskell, typeclasses make this super easy. It allows you define a family of functions/operators that together become what a Go or Java developer might call an interface. Code written to use a particular typeclass will work for any implementation of that typeclass.
On the other hand, OCaml's module system is very powerful and has no counterpart in Haskell. It allows you to package a whole type implementation into a single module that has a public signature, and can be instantiated with generic type parameters.
two sets of arithmetic operators for integers and floats
What if I want to create more numeric types? Say vectors in R^n, for example. Do I need to create more operators for vector addition and scalar multiplication? How do I make sure the user can’t add vectors of incompatible dimension?
Similarly, you cannot have a "print" function that works for all sorts of types. OCaml has print_string, print_int, and so on.
OCaml does have parametric polymorphism ("generics"). You can write functions which support generic parameters. And you can use modules as "functors" to sort of package up types in a similar way as Haskell typeclasses (e.g. see [1]).
[1] https://stackoverflow.com/questions/14934242/whats-the-close...
Is this taking into account backpack?
What do you mean by that?
But there is no reason to use it. Text does everything String does.
There is mess in these types. s9me libraries are using different types, so you might have to convert between those and it can be confusing, and the conversion apis are not unified. But if you manage in your project consistently use single type (say Text), then you'll actually have a great time working with strings. Its problem if you want to quickly mash together few libraries that does not use same types, since it get messy.
Reason for this is mostly historic.
Not exactly. ByteString has no relation at all with text or characters. It represents a sequence of bytes, AKA binary data.
I imagined I would hear complaints about too many text types when I made that question, but it sounded like the GP had a different complaint.
The library mess is real, but it's improving quickly and it's a bad reason to decide Haskell is a bad language to deal with text. It's throwing a lot of great stuff out just because of a minor inconvenient. And by the way, one of the best things on Haskell is that you can defined a lot more text types. For example, my current project has types for internal identifiers, HTML, HTML form values, JS, and SQL, they are all text but I can always be sure things are properly encoded.