Some of these points are a bit outdated. Ocaml improved a lot recently. > False Sense of Security This is a strawman argument. And the static types really do

Some of these points are a bit outdated. Ocaml improved a lot recently. > False Sense of Security This is a strawman argument. And the static types really do help, specially if you make good use of algebraic data types and the exhaustiveness checker. The autocompletion and documentation suport is also super nice. Installing Merlin is one of my top priorities when I set up an ocaml environment. https://github.com/the-lambda-church/merlin https://github.com/the-lambda-church/merlin > Few Basic Types Nowadays you tend to see tons of different integer types in systems programming languages (C, C++, Rust, etc). This is more the author saying he loves Common Lisp than a downside of Ocaml. > Module Immutability Can't you define a new module that wraps around the old one and overrides the `date_of_string` function? Changing the implementation of a module violates all sorts of abstraction guarantees and would lead to many thorny issues. > Polymorphism Causes Run-time Type Errors Polymorphic equality and comparison can definitely be a source of confusion. Hopefully in the future we will have module implicits and be able to solve this issue similarly to how Haskell does it. > No Macros Again, this is more of a "my language is not LISP" complaint. Ocaml has camlp4, which is not a full-blown macro system but allows for a large variety of syntactic extensions to the language. However, camlp4 was tricky to maintain in sync with the original language so nowadays the community is moving towards simpler ppx transformers: http://whitequark.org/blog/2014/04/16/a-guide-to-extension-points-in-ocaml/ http://whitequark.org/blog/2014/04/16/a-guide-to-extension-p... > Record field naming hell This got much better in more recent Ocaml versions, which let you have multiple records with the same field name living in harmony. > Syntax I'll have to agree with this one. Ocaml definitely doesn't have the prettiest syntax. > No (ad-hoc) Polymorphism This is a price to pay for keeping the type system sane. More flexible arithmetic coercion rules would also get in the way of type inference, which is a really nice thing about Ocaml. > Inconsistent function sets Its a bit less awful if you use one of the "replacement standard libraries", such as Containers, Core or Batteries. But yes, the suckyness of the standard library is a huge pain point. > Arithmetic's readability I don't think defining custom operators is as bad as the author thinks here. Their precedence is defined by the symbols you use so a new multiplication operators should behave similar to all the other ones. But yes, the monomorphic operators really are annoying. As I said before, I'm really looking forward to module implicits (sadly, it seems we'll have to wait at least until the version after the next one though) > Order of evaluation This one is even worse than he says. Order of evaluation is undefined and when compiling to bytecode its different from when its compiled to native code (one is left-to-right and the other is right-to-left) > No implicit forward declarations Being able to shadow existing definitions is pretty nice sometimes. Haskell does the "declarations are recursive by default" thing and it sometimes gets in the way. > Standard Library Sucks Can't argue against that. But at least there are replacement libs you can use to make it suck a little bit less. > OMake Nowadays I think people are moving towards ocamlbuild instead.