4 ms·

My biggest gripes are, in order: lack of library documentation, discoverability, maturity, and existence. Disclaimer: this is all anecdotal and the last time I

My biggest gripes are, in order: lack of library documentation, discoverability, maturity, and existence. Disclaimer: this is all anecdotal and the last time I dove into OCaml for side projects was about a year ago. 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.

jordwalke 9y ago
This is some solid feedback, thanks for taking the time to write it up. I work on ReasonML, so a lot of this feedback describes problems we’d like to help the OCaml community solve. We are making progress on the popularity front by leveraging the JS ecosystem and it is proving to be an effective approach due to the size and openness of the JS community. Meanwhile the OCaml ecosystem (libraries, compilers, build systems(see jbuilder and its docs)) have been improving in the last two years so I would recommend checking it out sometime soon again. I had a different experience with OCaml libraries. I’ve found some great gems in the OCaml ecosystem. For example, Menhir is an excellent parser generator used in Reason itself and it’s well documented and very powerful. I think many of these great pieces of the ecosystem stay hidden due to the exposure problem you mentioned, which comes back to popularity. Another major missing piece of the library story was a way to build web apps using the most common web frameworks so we developed Reason React as part of the ReasonML project. https://reasonml.github.io/reason-react/ https://reasonml.github.io/reason-react/ It’s definitely not a “bolted on” approach to React - it’s carefully thought out and in my opinion the API improves significantly upon React in ways that can only be done with language level type system features. Reason React is how I wish React always was. Apologies for hijacking the GraphQL library thread to plug our project.
- kornish 9y ago
  My pleasure, Jordan - thanks for the great work you and your team do on ReasonML. I agree that OCaml has some brilliant libraries for problems which are, in other languages, difficult or unpleasant to solve (parsing being one of them). Menhir is wonderful. However, that doesn't preclude gripes 3 & 4 from above. If a language seeks to be general-purpose, the existence of some truly great libraries doesn't redeem a need for dependable solutions to a multitude of problems. I think OCaml can have a place in an organization's software stack today - but it will not gain the spotlight until its library offerings have the variety, robustness, and accessibility of other ecosystems. Would I write an internal parsing service using Menhir and expose over Protobuf? Absolutely. Would I write a heavier-duty application server that had to parse something, then talk to Postgres? Perhaps not - and that's a shame. Love Reason React. I'm a huge static typing proponent where possible, and combining the semantics of OCaml with React is a great move. Writing the occasional typed FFI wrapper into a Javascript library isn't the worst thing in the world. Most of my complaints for libraries center around server side OCaml/ReasonML development, which is where I have the most experience. (and that experience is admittedly limited)
ernst_klim 9y ago
>crontab parsing and execution 10 minutes with angstrom and unixlib? Sure, ocaml does not have javascript/go-style libs like leftpad, but it provide a great ability to solve generic tasks with more generic libraries like angstrom, menhir, faraday, lwt or react. >I can't in good faith recommend it for building production systems to interact with the outside world Why is that so? I believe in exactly opposite. We are building quite a big telecom infra with ocaml, and it shines. In really critical systems (something beyond silly guest pages) you can't rely on low quality third party libs (which are usually provided by go), you have to write things by yourself or use some very generic stuff, and that is where ocaml shines. Both the language and major libs in opam are of an outstanding quality, people behind mirage, ocaml, angstrom, react, lwt are so collaborative and smart, and libraries are so transparent and beautiful that it is easy to understand how things work and what's happening under the hood.
- kornish 9y ago
  Totally fair - no experience here in deploying OCaml for production. Agreed that the language and major libraries are phenomenal. My intuition is that the maintenance time cost of writing and extending these abstractions from scratch in the face of changing business requirements is higher than the time cost of using a less perfect language but richer ecosystem; but that could be totally wrong. Glad the language is shining in your situation. Can you elaborate more on team composition, tenure, learning curve, and use case? > 10 minutes with angstrom and unixlib? https://github.com/robfig/cron https://github.com/robfig/cron is ~1.5KLOC - sure, it's Go, but that's a bit more than 10 minutes in any language, especially to change gears and think through edge cases. I'd prefer for things to Just Work. > low quality third party libs (which are usually provided by go) My experience with Go libs is that because the ecosystem is large and expanding fast, a surprising number of problem domains have one or two great standout libraries among a ton of noise. But it turns out one or two great libraries is frequently all you need. I dislike the language from a theoretical standpoint but after working full time in it for several years, can't deny that it's good for Getting Shit Done.
  - ernst_klim 9y ago
    >requirements is higher than the time cost of using a less perfect language but richer ecosystem; but that could be totally wrong. Believe me, breakdowns will cost much more, especially if your device has no ssh, connected via ASI/some military obscure one-directional interface. I found that in many fields it's incredibly hard to approve third party libs usage, even some basic stuff like boost. >~1.5KLOC - sure, it's Go, but that's a bit more than 10 minutes Well, it is Go. This is go json parser: https://github.com/buger/jsonparser/blob/master/parser.go https://github.com/buger/jsonparser/blob/master/parser.go And this is angstrom: https://github.com/inhabitedtype/angstrom/blob/master/examples/rFC7159.ml https://github.com/inhabitedtype/angstrom/blob/master/exampl... cron should be easier, it's either vars or cronlines, which are trivial. I prefer to write it in angstrom than to catch some unexpected panic in go because of type coercion or similar shit.

jordwalke 9y ago

This is some solid feedback, thanks for taking the time to write it up. I work on ReasonML, so a lot of this feedback describes problems we’d like to help the OCaml community solve. We are making progress on the popularity front by leveraging the JS ecosystem and it is proving to be an effective approach due to the size and openness of the JS community. Meanwhile the OCaml ecosystem (libraries, compilers, build systems(see jbuilder and its docs)) have been improving in the last two years so I would recommend checking it out sometime soon again. I had a different experience with OCaml libraries. I’ve found some great gems in the OCaml ecosystem. For example, Menhir is an excellent parser generator used in Reason itself and it’s well documented and very powerful. I think many of these great pieces of the ecosystem stay hidden due to the exposure problem you mentioned, which comes back to popularity. Another major missing piece of the library story was a way to build web apps using the most common web frameworks so we developed Reason React as part of the ReasonML project. https://reasonml.github.io/reason-react/ https://reasonml.github.io/reason-react/ It’s definitely not a “bolted on” approach to React - it’s carefully thought out and in my opinion the API improves significantly upon React in ways that can only be done with language level type system features. Reason React is how I wish React always was. Apologies for hijacking the GraphQL library thread to plug our project.

kornish 9y ago
My pleasure, Jordan - thanks for the great work you and your team do on ReasonML. I agree that OCaml has some brilliant libraries for problems which are, in other languages, difficult or unpleasant to solve (parsing being one of them). Menhir is wonderful. However, that doesn't preclude gripes 3 & 4 from above. If a language seeks to be general-purpose, the existence of some truly great libraries doesn't redeem a need for dependable solutions to a multitude of problems. I think OCaml can have a place in an organization's software stack today - but it will not gain the spotlight until its library offerings have the variety, robustness, and accessibility of other ecosystems. Would I write an internal parsing service using Menhir and expose over Protobuf? Absolutely. Would I write a heavier-duty application server that had to parse something, then talk to Postgres? Perhaps not - and that's a shame. Love Reason React. I'm a huge static typing proponent where possible, and combining the semantics of OCaml with React is a great move. Writing the occasional typed FFI wrapper into a Javascript library isn't the worst thing in the world. Most of my complaints for libraries center around server side OCaml/ReasonML development, which is where I have the most experience. (and that experience is admittedly limited)

ernst_klim 9y ago

>crontab parsing and execution 10 minutes with angstrom and unixlib? Sure, ocaml does not have javascript/go-style libs like leftpad, but it provide a great ability to solve generic tasks with more generic libraries like angstrom, menhir, faraday, lwt or react. >I can't in good faith recommend it for building production systems to interact with the outside world Why is that so? I believe in exactly opposite. We are building quite a big telecom infra with ocaml, and it shines. In really critical systems (something beyond silly guest pages) you can't rely on low quality third party libs (which are usually provided by go), you have to write things by yourself or use some very generic stuff, and that is where ocaml shines. Both the language and major libs in opam are of an outstanding quality, people behind mirage, ocaml, angstrom, react, lwt are so collaborative and smart, and libraries are so transparent and beautiful that it is easy to understand how things work and what's happening under the hood.

kornish 9y ago
Totally fair - no experience here in deploying OCaml for production. Agreed that the language and major libraries are phenomenal. My intuition is that the maintenance time cost of writing and extending these abstractions from scratch in the face of changing business requirements is higher than the time cost of using a less perfect language but richer ecosystem; but that could be totally wrong. Glad the language is shining in your situation. Can you elaborate more on team composition, tenure, learning curve, and use case? > 10 minutes with angstrom and unixlib? https://github.com/robfig/cron https://github.com/robfig/cron is ~1.5KLOC - sure, it's Go, but that's a bit more than 10 minutes in any language, especially to change gears and think through edge cases. I'd prefer for things to Just Work. > low quality third party libs (which are usually provided by go) My experience with Go libs is that because the ecosystem is large and expanding fast, a surprising number of problem domains have one or two great standout libraries among a ton of noise. But it turns out one or two great libraries is frequently all you need. I dislike the language from a theoretical standpoint but after working full time in it for several years, can't deny that it's good for Getting Shit Done.
- ernst_klim 9y ago
  >requirements is higher than the time cost of using a less perfect language but richer ecosystem; but that could be totally wrong. Believe me, breakdowns will cost much more, especially if your device has no ssh, connected via ASI/some military obscure one-directional interface. I found that in many fields it's incredibly hard to approve third party libs usage, even some basic stuff like boost. >~1.5KLOC - sure, it's Go, but that's a bit more than 10 minutes Well, it is Go. This is go json parser: https://github.com/buger/jsonparser/blob/master/parser.go https://github.com/buger/jsonparser/blob/master/parser.go And this is angstrom: https://github.com/inhabitedtype/angstrom/blob/master/examples/rFC7159.ml https://github.com/inhabitedtype/angstrom/blob/master/exampl... cron should be easier, it's either vars or cronlines, which are trivial. I prefer to write it in angstrom than to catch some unexpected panic in go because of type coercion or similar shit.