Standard ML was my favorite language 2008-2012, and whenever people criticize the syntax, I shake my head. ML syntax is among the most beautiful, and most readable, to me. OCaml has a few features that bring the readability down a little, like the named fields prefix. The fact that it doesn't look like C or Ruby isn't bad. Erlang can be very readable, it just feels alien, which I presume is what people don't like.
The big downside is the paradigm shift + inscrutable error messages.
It will make you feel dumb and/or unproductive for a very long time.
A lot of the type errors can be fixed by a compiler that cares more about error messages, and OCaml in particular could do well with terminators after e.g. match blocks to improve both ambiguity and error reporting. Some of the type errors can't easily be fixed; wrong function application by omitting some value somewhere has, so far, always led to misleading errors; are there any other examples than Elm that address these?
I also switched from ML to Haskell to Rust.
To me, the main downside of ML is the explicitly instantiated module systems not tied to the filesystem hierarchy.
Once you get used to traits and parameterised trait instances, bringing every module instantiation into scope after separately importing them is just slooow.
The standard library situation is also somewhat not great. Maybe I just never got used to it, but I sense that there are people think Jane Street Base is a must, and people who think it's completely overkill. OCaml programmers have a weird fetish with micro-optimization because the compiler lets you think about the asm output. It's a remarkable property of an otherwise high-level language that you can really care about the asm output.
> OCaml in particular could do well with terminators after e.g. match blocks to improve both ambiguity and error reporting
You can use either begin/end or parentheses as terminators around any blocks of Ocaml for exactly that purpose.
> To me, the main downside of ML is the explicitly instantiated module systems not tied to the filesystem hierarchy.
That's one of the greatest strenght of ML actually and especially Ocaml where parametrised modules are everywhere and a required building block of generic code. A significant part of why the article complains about type for exemple is because the author doesn't know how to use the module system.
> Once you get used to traits and parameterised trait instances
I like modules a lot more. It makes the code a lot clearer than traits.
> The standard library situation is also somewhat not great. Maybe I just never got used to it, but I sense that there are people think Jane Street Base is a must
The standard library is a lot more complete nowadays that it was some years ago and Base is used by pretty much nobody outside of JaneStreet.
The big downside is the paradigm shift + inscrutable error messages.
It will make you feel dumb and/or unproductive for a very long time.
A lot of the type errors can be fixed by a compiler that cares more about error messages, and OCaml in particular could do well with terminators after e.g. match blocks to improve both ambiguity and error reporting. Some of the type errors can't easily be fixed; wrong function application by omitting some value somewhere has, so far, always led to misleading errors; are there any other examples than Elm that address these?
I also switched from ML to Haskell to Rust.
To me, the main downside of ML is the explicitly instantiated module systems not tied to the filesystem hierarchy.
Once you get used to traits and parameterised trait instances, bringing every module instantiation into scope after separately importing them is just slooow.
The standard library situation is also somewhat not great. Maybe I just never got used to it, but I sense that there are people think Jane Street Base is a must, and people who think it's completely overkill. OCaml programmers have a weird fetish with micro-optimization because the compiler lets you think about the asm output. It's a remarkable property of an otherwise high-level language that you can really care about the asm output.