It also summarizes some of my other views about Ocaml in general and the elephant in the room: OCaml vs Haskell. Check it out and let me know if you agree with some of the points I’ve made!
i generally agree, but i’d say we need a lot more marketing and better documentation in libraries because a lot of stuff can be daunting when starting out.
Also dont forget scala 3 with its reimplementation of type system. Hkts, type-classes, mainstream object method syntax, intersection types and union types,first class macro system, compiler is a lot faster than it used to be, but it still has jvm which is a blessing and a curse, people still cling to old versions of jvm and scala.Also libraries wont be ported to scala 3 until a few years from now. so it’s not only haskell that’s competing with ocaml, but also scala. But i believe ocaml has a chance to bite some part of scala’s mindshare with upcoming releases and features as multicore, effects(probably will land in scala too in few years), implicits, namespaces and maybe ergonomic higher kinded types
edit: i also forgot to point out that ocaml is a lot faster than fp scala in majority of cases and has a lot more usable apis, so that maybe a pro for some people that care about such stuff
I think there is a case to be made that OCaml is not as featureful or high powered as language X and that is a good thing. The less high powered or abstract your language is, the (a) Easier it is to grok (b) Easier to product efficient code for.
Scala is clearly trying to go in the direction of Haskell. I think OCaml apart from adding a few features here and there in the future should continue to be a slightly conservative language as it is today. I personally would love typeclasses in OCaml. Having used typeclasses (Traits) in Rust (apart from seeing in in Haskell of course) is just a game changer in terms of expressiveness.
Some configuration languages like to advertise that they are not turing complete. In a similar vein I appreciate a general purpose language telling me if they don’t have every feature and the kitchen sink in it. I like languages that plan to remain limited in certain respects…
You make some great points. This is a really good post. But I would like to respond to a couple of things.
First, I don’t think anyone is seriously saying that OCaml’s state of tooling is ‘pathetic’
Yes, there are always improvements to be made, and people are continuously making them. Yes, the Windows situation is confusing, and people are trying to improve it. I think it’s fair to say that while experienced OCamlers like the current state of tooling with opam and dune, many people would like an integrated toolchain as easy as Node.js or (another shining example) go.
Second,
…overall decline of Windows as a development platform … since the cloud is basically Linux based it makes sense to develop on a Unix like platform. Even on the client side (Android and iOS) you basically have Linux/Unix
I think this is missing the fact that not everyone is making a backend service to run on the cloud. Many people are also writing CLI tools in OCaml. Some are also writing desktop apps! And Windows is still indisputably the king of the deskop OSs, there’s just no getting around that. We can try to rationalize it away, but the fact is that OCaml needs Windows (and, as discussed in the earlier thread, it already has the Windows support, just needs some polishing and buffing in a few places).
I agree with you, except for the Windows opinion which @yawaramin has already pointed out.
I learned OCaml but I took a break because I found its abstraction facilities lacking. HKTs (which will enable type classes), metaprogramming (Scala 3 shines here) and modular implicits will go a long way, but I fear that they may increase compile time. I’m also waiting on multicore.
I personally would love to see something like this or a general state of the union report (similar to haskell’s sotu or the outdated ocaml sotu) written by a random community member each year, and highlighted on the ocaml.org homepage. I think it would help set expectations for people new to community.
Really nice post. Since others have listed their gripes about the post, I’ll add mine to the list.
For OCaml to achieve more “success” (at least as GitHub defines it: more programmers, more stars, more repositories, more contributions from people not directly associated with a project) the current crop of OCaml programmers simply have to build some cool projects.
I don’t really buy the whole “build cool things, they will come” argument. I don’t think there are satisfying answers to “what are cool projects in Haskell, Python, Scala, Rust, etc and how have they attracted non-institutional programmers”? All of these languages have really cool projects (and so does OCaml), but I’m not convinced that cool projects make predictable contributions to the number of people writing software in the language.
There are many reasons why people don’t use OCaml, and they all make sense.
OCaml doesn’t have the same sex appeal as Haskell: laziness, typeclasses, pretty syntax, list comprehensions. (yes, modules are sexy, but not enough to win over Haskellers)
OCaml doesn’t have the same beginner friendliness as Python.
OCaml doesn’t have numpy and the community around it.
OCaml doesn’t have tensorflow/pythorch and the communities around them.
OCaml doesn’t have Rails and the community around it.
OCaml doesn’t have the same compatibility with Java libraries as Scala.
OCaml isn’t the main way to develop in a platform like JavaScript, Objective-C/Swift, Java/Kotlin are.
OCaml isn’t as fast/bare-metal as C/C++/Rust.
OCaml isn’t backed by large companies like Java, Go, C#, etc.
OCaml isn’t taught in as many CS/SE programs as C/C++/Java/Python/etc.
… and the list goes on
When I use OCaml, most of the time it makes sense for me to use it, and I sometimes go out of my way to use OCaml because I enjoy using it. I find that OCaml strikes a particularly nice balance between safety, dynamism, and speed, but the strengths of OCaml doesn’t seem to matter to other people and I’ve come to terms with other languages being more popular.
The core thrust of my argument was that OCaml, while lacking some some advanced functional language features of Haskell was a well balanced system i.e. good binary size, convenience of gc, minimal tuning required, no mysterious issues during runtime, decent performance, great compile times etc. It is due to these tradeoffs, OCaml is a brilliant language. Some people (I’m not saying all people) often fixate on a single aspect of a language and think it is brilliant: E.g. the hyper expressivity of Ruby, Haskell’s great type system, Python’s wonderful pseudocode like syntax etc. But the real power and brilliance of a language is that it needs to be well rounded – which OCaml certainly is. Ruby and Python were not initially engineered with type checking in mind. Haskell has a great type system but has other issues which I mention in my blogpost and so on…
So I was urging to people to judge languages on this aspect of well roundedness/balance and come to OCaml for that reason.
At some point in the past, some engineer or team of engineers chose those languages to build these wildly successful ecosystems. So I’m urging people to consider OCaml as a foundation for their next project (which who knows, could get big) for the reasons I outlined in the blog.
Yes, its tough uphill climb and as other ecosystems continue to gather more and more important anchor projects (Rails, numpy etc. are good examples of anchor projects) it will be tough for OCaml to make a mark.
However, there is a huge amount of innovation still left and who knows, the next cool project someone makes could be in OCaml. I recently found out to my pleasant surprise that GitHub - facebook/pyre-check: Performant type-checking for python. is built in OCaml – not exactly something that will be a rails or a numpy but it is something important nevertheless.
I think what the original poster meant was that we don’t have the specific numpy project which has now become a huge anchor project for open source scientific computing.
Owl definitely seems cool and could be the base on which OCaml people build some cool stuff going forward.
Thanks for poking at this issue @sid Apologies for the wall of text to follow
Disagree on the Haskell somewhat, it is eminently practical, tracking side effects is a fantastic feature. Knowing there is an STM or IO in the type signature reveals important detail. Monad Transformers (or Effects) are as much familiarity as complication. Getting to the familiarity point is tricky best done with supervision from an experienced mentor, without well I think that is where Haskell is really hard and makes for horror stories about people bouncing off the language in frustration
Strongly agree with the tooling blessed path:
dune
opam
lsp with VSCode (or other editor)
ocamlformat
The documentation piece still needs work and I wouldn’t point to docs.ocaml.pro as a hoogle equivalent.
Type directed search is still pretty rough as a user, in Haskell I would have a local hoogle based off my
current project installed and search libraries / my code for types or functions. That workflow in OCaml is
usually via google or grep and not at all seamless.
utop is weird as you said it’s more limited than ghci or cabal repl, I only use it for very
specific small tests in my day to day work. eg today messing with Hash algorithms Mirage_crypto.Hash.SHA256.(hmac ~key body)
GHC/Haskell build times are indeed pretty nasty, better now with newer cabal and dependency caching.
I feel that Haskell programmers ask the compiler to do a lot more work than is typical in OCaml, for example Template Haskell doing code generation, deriving typeclasses, along with my favourites of Functional Depedency solving / Type Families. Even with that an equivalent sized Haskell project is slower than an OCaml project.
The issue with OCaml tooling is mainly down to polish and documentation (many of the pieces are
there or being actively worked on just not as well documented as Rust), it has come a huge way over
the last few years (do not want to deal with Oasis again). Not being a Rust programmer, could you
talk more about which things cargo does that are missing in OCaml?
@lambda_foo thanks for the counter viewpoint on Haskell. Its important for there to be discussions on this issue. Like I said, I don’t like to be in any single language camp. I feel I can feel part of many language communities simultaneously and appreciate many languages.
I’ve played around with Monad transformers in Haskell I think sufficiently by now. But somehow I still feel unimpressed – it can shine when you are, say, building a interpreter for a language but in some other places I find the lifts, liftIOs etc. a bit annoying. (Thought I’m sure there are a lot of advanced patterns that allow you avoid lifts and make things more generic). I personally find the “book keeping” and thinking about where I am in the transformer stack a bit exhausting. Then I find errors and exceptions quite tricky especially when we are in a monad transformer. Maybe I need to use it more so that it becomes second nature to me.
Doesn’t Haskell have big binary sizes? For instance my locally built binary of the haskell language server is 100M+. Though ocamllsp does not do as many things as the haskell language server it weighs in at mere 19M in one of my opam switches
Have you had to deal with space leaks and what are your views on that? To me this is absolutely terrifying. The funny thing is that Haskell has given you strong guarantees in your strongly typed program that certain things will not go wrong. But then its runtime reserves the right to space leak at anytime and mess things up. It’s like Haskell gives with one hand but takes away with another. How do you deal with this possibility because it does not seem to be easy to debug space leaks. Plus space leaks can spring up when certain non-common code paths are run during production. The whole point of Haskell is to give compile time guarantees. But space leaking is actually an anti-gaurantee.
I’ve seen people tune Haskell programs and the end result to me seems like very unidiomatic Haskell code. The declarative beauty of Haskell code with all kinds of bangs, rewrite annotations (that are fragile BTW) seems to go away for me. As a small experiment, please check out the OCaml and Haskell examples on the languages benchmarks game. In an effort to get the maximum performance, the Haskell code looks so complex and mangled. In comparison, the OCaml code seems pretty much what a non-expert might end up writing. Haskell tends to be very succinct but most of the language benchmarks game examples tend to much longer than OCaml (see the “gz” column. That is the gzipped size of the code).
There is no denying that OCaml is lacking some important features and facilities one expects from a language in 2021. But I think Haskell seems to get a free pass in some major areas and I think people need to take that into their calculations when choosing Haskell or arriving at an assessment of the language as a whole.
Coming to your other points: I like how cargo suggests possible solutions for problems. If something does not work it and there is a configuration option that could solve it, it will tell you to check out that out. For example, when you compile with dune it will fail the compile on warnings. This is perplexing for beginners. It would be awesome if dune told you how to disable warnings-as-errors by adding (env (flags (:standard -warn-errors -A)) to your dune file. Cargo would never just barf on the problem, it will often try to suggest a solution.
Interestingly, the haskell language server has the equivalent of cargo clippy in the form of hlint which can help introduce some consistency in your code though sometimes the suggestions seem a bit pedantic/pointless.
Indeed docs.ocaml.pro does not yet come close to hoogle. But its in the same ballpark and has the potential to become much better. Its been helpful to me when I’ve wanted to look up certain things documentation wise and not have to install that package locally. Yes, type-directed function search is one of Haskell/Hoogle’s super powers.
I’m kind of working on this. The current plan is to test it on students on upcoming semester and release a tool in January/February with some understanding how good it is.
I think this is missing the fact that not everyone is making a backend service to run on the cloud. Many people are also writing CLI tools in OCaml. Some are also writing desktop apps! And Windows is still indisputably the king of the deskop OSs, there’s just no getting around that.
I must have been looking elsewhere, but how are people writing desktop apps with OCaml? Do we now have a portable GUI library that’s so easy to use that setting up OCaml on Windows is comparatively hard? What is it?
Last time I’ve used it (admittedly, long ago) it was not trivial to make it work on Linux due to the many breaking changes in gtk libs. A cursory look at lablgtk homepage indeed reveals that it’s still maintained, and support recent enough gtk versions. Also installation on window seams doable yet not straightforward. Good to know.
That being said, I still very much doubt access to gtk3 is the reason why some developers insist to stick to windows, therefore the advice to move to unix sounds sensible to me (in order to improve their dev experience with OCaml as well as a general advice).
It’s not that developers are ‘insisting’ to stick to Windows because of this or that reason, it’s more that that’s the OS they know and have access to; they can’t use anything else. This can be for a variety of reasons: corporate decision to give developers Windows laptops, or students/researchers having access to Windows machines only, or working on personal machine which only has Windows. For whatever the reason, it doesn’t change the fact that Windows still has the biggest share of the PC market. My point is that OCaml can gain a much bigger potential audience by having a smooth Windows story, than by insisting that devs move to Unix.
