Type-safe GraphQL with OCaml

1. Documentation. Anecdotally, when you find a library that's not by Jane Street or top-20 starred on GitHub, the odds are low of finding a useful README or example code. God bless the developer if there are tests, but that seems to be rare as well.

2. Discoverability. OCaml's ecosystem sees tons of code for useful but non-major tasks floating around in various GitHub repos, where installation is tricky. I want to use a part of speech tagger? Great, I found a library with no documentation on GitHub - now how do I get it into my application? Why isn't it in the OPAM repo? I found an elasticsearch client library with no documentation on GitHub? Great - now why isn't it in the OPAM repo.

3. Maturity. Of the myriad library code floating around on GitHub, very little of it is what I would consider production-ready, by merit of lack of testing, lack of community, lack of documentation, and lack of frequency of updates.

4. Existence. Frequently, libraries don't exist which do in other languages. In the past couple weeks, I've pulled in Go and Java libraries for crontab parsing and execution, a MySQL ORM, inflection of English words, and various NLP utilities like the Stanford parser.

All languages have these problems to some degree, but the fact of the matter is that while OCaml is a beautiful language for closed domains, I can't in good faith recommend it for building production systems to interact with the outside world. Other languages give you many of the benefits of the type system with much less of the hassle (looking at you, Kotlin). Writing production systems in OCaml can be done, absolutely - my hat is off to Yaron Minksy and the folks at Jane Street - but there are tradeoffs.

And we're not even getting into developer tooling; this is just libraries.

All counterarguments welcome; it'd be wonderful to hear that OCaml is gaining in developer productivity and production readiness over time. I have great faith that ReasonML can get lots of Javascript folks more interested, and the increased demand for libraries should hopefully lead to the filling of holes in the ecosystem. Most of OCaml's problems stem from it being simply unpopular.

Static methods are just plain functions tied to classes from an era when people thought having classes everywhere is actually a good idea, in C# and F# also tied to weird, magical compiler rules around operators.

Speaking of Smalltalk and OOP, operators like "+" in languages like Smalltalk are object methods and can be used in generic functions doing polymorphic calls. In OCaml they are plain functions with no overloading. In Haskell they are functions requiring type classes to work, sort of like what F# is doing, but non-broken.

Btw, if you're wondering from where the convention of using static methods for operators comes from, that's another relic of C++, a language not known for elegance, finesse or for being a good OOP language.

That's interesting, as being forced to use the same operator for addition and for concatenation (and what's more with the result of mixed types if allowed often dependent on the order of the parameters) has always seemed extremely inelegant to me.

Addition and concatenation are not the same thing. Why they should share a symbol when they don't share some properties integral to their nature (it's non-commutative) is beyond me, and I think it's caused a lot of bugs that didn't need to happen.

Not allowing the addition of floats and ints together is less of a fundamental issue, but it also helps quite a few problems. Al alternative solution, if you didn't want to reply on implicit coercion would be to explicitly convert one operand to the appropriate type so they match.

Or you can go whole hog and provide an entirely separate set of operators for different types, like Perl did (string concatenation is '.', and equivalents comparitors are eq,ne,gt,lt,ge,le). That works well in Perl's case, but that's mostly because for Scalars Perl really just wants to know whether you are treating it as a number or a string, so there's only two types to account for.