My biggest frustration with the Ocaml is with third-party libraries documentation. The majority of the docs are just function signatures without explanation, let alone usage examples.
The language however is quite nice and the stdlib is fairly complete.
Edit: Another problem I see is the (over?) reliance on PPX preprocessors. It does make a lot of tasks simpler, but it is too much magic for me personally.
It's funny that I could say the opposite about Rust if you asked what I enjoy most about the ecosystem - many third party libraries have outstanding documentation. Wonder why is that - in the end, it's just some folks like you and me spending their free time writing those. Why is it different for different languages then, is it the tooling like rustdoc and docs.rs or just the standards set by the community? Not sure.
I've not been deeply involved in either so take my hunch for what it is:
OCaml is an academic language like Haskell. Academics tend to neglect documentation in general, be it because what they're working on is mostly self-serving, lack of time/enthusiasm or a tinge of elitism on that "this should be obvious and if not just read the code".
Rust adherents seem to really want to take over the world and they realize that great documentation is an enabler for that.
Also the standard libraries and compiler set a pretty strong precedent.
It is a complete and up-to-date manual of the entire OCaml distribution, including executables, language, runtime, and standard library. It's rare to find modern industry-driven languages with this level of coherent documentation.
But regarding third-party library documentation, that is indeed spotty. Some people publish it, some don't. I have to reluctantly conclude it's due to a lack of tooling which automates the tedious processes.
Some of it can be driven by external factors: javascript was the only choice for an important domain for a long time.
Some if it I think is due to attractive syntax, or tooling. Python for example, horrible runtime performance, but people were drawn to it for probably syntax and tooling reasons.
Comparing Rust and OCaml:
The OCaml syntax is a bit odd. I was quite taken by F#, which is a very similar language to OCaml, but with some of the cumbersome syntax removed. F# seemed quite nice, looking at OCaml it just felt horrible and I didn't want to deal with it. In practice I know it would be fine, just like you get used to Lisp and it's parens, but there is a real psychology there that turns people away.
OCaml has good runtime performance, but its not the kind of language that will draw in C/C++ programmers or work for domains where you need C or C++ currently. Lack of multi-core is a huge turn off for a lot of people. This is the era where multi-core is our only path to more performance!
Rust syntax is a little more familiar to people, the runtime performance is top notch, very good at leveraging more cores, and maybe most importantly the community has made a concerted effort to make the language as approachable as possible. With good/friendly documentation and community. Easy install process, decent editor support, etc. Go ask a question about "Which way is faster" in a C# forum, you get a lecture about how you shouldn't worry about that. On a Rust forum you get an deep dive into performance concerns and language design. This seems to have drawn in people from communities you wouldn't expect. A low level, complicated language that Ruby and Javascript developers are drawn to? An interesting result!
> Python for example, horrible runtime performance, but people were drawn to it for probably syntax and tooling reasons.
Tooling? How so? Like the REPL? Because when I think of tooling, I think of things like IDEs, dependency management, and distribution. Python has one of those things now (IDEs/notebooks), but even that took a while, IMO.
Python is a weird case study for me. I'm not trying to flame war or anything- just pointing out my own blind spots and/or biases. But I just don't see much of anything redeeming about the language. It can be pretty easy to read, but I don't think most code I've seen actually is easy to read/follow.
I think it's worth keeping in mind that when Python got popular, there weren't options like Go or Node (or any other big player in server-side JS) that might hit different points on the performance versus ease of writing tradeoff. My understanding is that Python took off in a world where the other choices for languages were things like Perl and Java. Compared to Perl, Python does have a reputation of being much more readable, and compared to Java, it has the reputation of being much easier to write. People were attracted to the language initially for that, and then as the community grew, other benefits started appearing, like a rich ecosystem of third-party packages. Nowadays, other languages have appeared that offer different productivity tradeoffs, some with much better performance, so it's possible that Python won't be the first choice of as many people as before, but I don't think it's particularly surprising that people who have used it and been productive with it for years still continue to enjoy working in it. The experience of working in a language like Python hasn't actually gotten worse just because something like Go exists; it's just that some people who might have picked Go over Python 20 years ago picked Python back then because Go didn't exist yet.
I can't speak for others but for me it is the tooling. Knowing that I can get great online doc with a single command is a very good motivation to start writing said documentation.
I second this. I dislike the liberal usage of metaprogramming, especially in the context of a code base that you have to work on with multiple people. It adds another layer of concepts/complexity/magic that everyone in the team has to learn.
With PPX, the barrier to use metaprogramming has become lower (especially compared to camlp4), resulting in most modern Ocaml codebases depending on it. But the ergonomics of the end-to-end software delivery have not really followed: the fact that PPX's break between compiler versions means that in practice, a compiler upgrade becomes a very costly thing to do. It is difficult to make the case for this in an industrial setting, where languages with almost religious backwards compatibility are common (Java, C++, even Go). For Ocaml, it is especially sad, because the core language is already quite powerful and expressive, lowering the need for metaprogramming (imo).
For scenarios where code generation is needed, I prefer a separate code generation step, which produces explicit "standard" code (e.g. like protoc)
Ocaml is rock solid as a foundation, yet the ecosystem appears to be very fragmented. For example, not only does Ocaml not support unicode strings natively, there are several competing libraries offering this functionality. This is just bizarre. Why is it like this? Not unicode specifically but like, in general. Doesn't Ocaml have some kind of language improvement process?
Yes, it does. However a lot of it is driven by long-time ecosystem contributors and they generally work somewhat behind the scenes, presenting on the progress ~annually at conferences like ICFP. Here's the latest progress report, in case you're interested: https://www.youtube.com/watch?v=E8T_4zqWmq8
Now this is not the same language/community improvement system that many popular projects nowadays use, but OCaml has been stewarded in its way for a few years now, and it's something the contributors feel is sustainable given the size of the project and the resources available.
About Unicode specifically, there is of course support at the library level as you mentioned (the most well-known library is Camomile), but to try to justify not including it in the language distribution itself, to a certain extent many applications just don't need it. Those that do can of course use libraries, but many (say, backend servers) don't really need to process Unicode strings, they just need to shovel bytes from point A to point B and not actually touch the contents.
> many applications just don't need it. Those that do can of course use libraries, but many (say, backend servers) don't really need to process Unicode strings
I can't speak for actual Ocaml users, but I've personally rejected Ocaml for my user-facing webapps because of things like this. Treating unicode as something optional was fine for early 2000s, but it's really not fine today. Most user facing applications need first class support for internationalized strings much more than other stuff like Big_int that's actually implemented in Ocaml stdlib.
I'm guessing the status quo works fine for existing Ocaml users, but that's kinda circular, and would explain Ocaml's limited adoption outside of its traditional niches.
> Treating unicode as something optional was fine for early 2000s, but it's really not fine today. Most user facing applications need first class support for internationalized strings much more than other stuff like Big_int that's actually implemented in Ocaml stdlib.
This is certainly a valid argument, but honestly most languages handling of Unicode is really poor to the point where I actually prefer OCaml's not handling it since then I can use dbunzli libraries and get stuff to work correctly. Just try reversing a Unicode string and you'll see all kind of languages "with Unicode support" fail miserably, e.g reversing 🇺🇦 into 🇦🇺.
Go outside the BMP and see how nearly nobody has bothered to implement proper support for Unicode glyphs, let alone word boundaries etc. Swift might be one of the exceptions but outside of that? Bummer. Bonus points to Python 3 for breaking compatibility because of Unicode and then doing it wrong anyway.
Actual ocaml user here. User-facing web apps just aren’t a core application target for most people who use Ocaml, and probably won’t ever be. There are many perfectly good languages out there that address that need, so if ocaml doesn’t, so be it.
Maybe I’m just in the minority - I like the fact that there are lots of languages out there, some of which choose not to cater to every possible development scenario. This is why I know lots of languages - instead of trying to apply one to every situation, I look at a situation presented to me and can go into my mental toolbox to pull the right language out for the job. I don’t see language design/implementation as a competition to acquire users. Do a job, do it well, and some subset of people will be happy - those that aren’t can move along and continue browsing the catalog of languages until they find one that meets their needs.
The ML family is really good at (safe!) string processing, e.g. the meme that they're only good for writing compilers.
Lots of Web stuff is just that (DB queries, GET/POST parameters, HTML, templating, URLs, JSON, XML, etc.). Whilst lots of that can be done via bytes, there are certainly cases where Unicode is needed (e.g. finding word boundaries, case-insensitive comparison, etc.).
Ocaml (and SML) have the enviable position of being safer+faster than scripting languages, and more approachable+familiar than the likes of Haskell (which otherwise has a similar feature set). That makes it very well suited to such domains IMHO.
^ This. Exactly my experience with it. Though, recently I'm using Java when I work with others on cloud-related projects and Scala (which is a ML+typeclasses+concurrency on the JVM) to write a compiler for OpenCL. For me, OCaml is great if you want compilation speed, fast iterations. Lacks in other departments: concurrency, parallelism, ergonomics, availability of libraries (outside compiler territory). Also, there's Flix that can have a lot of potential in the future, which is on JVM also: https://flix.dev/
Even if you need, for example, word boundaries, you might be better off pretending that no non-ASCII non-word chars exist than pretending that everything is valid UTF-8 or whatever. Depends on your inputs and requirements.
> User-facing web apps just aren’t a core application target for most people who use Ocaml, and probably won’t ever be.
Some industrial Ocaml users use the web as a UI. I'm fairly certain Jane Street does it for exemple. That's very much user-facing web apps.
I understand that it's not something that interests you but there has been plenty of work geared towards building web applications in Ocaml (and Reason). Saying it probably won't ever be a core application target seems quite wrong.
> User-facing web apps just aren’t a core application target for most people who use Ocaml, and probably won’t ever be.
I wouldn't be so sure. The way that the ReasonML and ReScript communities have been attracting frontend developers, webapps may already be the single biggest target platform for OCaml (well, a derivative) today.
I am not american and use a european alphabet with more characters. So if I need to handle user input or parse files with data I need unicode handling, so even for non web apps it can be needed.
I am not american and use a european alphabet with more characters. So if I need to handle user input or parse files with data I need unicode handling, so even for non web apps it can be needed.
And yet OCaml is French and its French authors do not feel constrained by the lack of unicode or they would have "scratched their own itch".
No. You can get similar language-level benefits from languages with stronger ecosystems around web-relevant technologies. For example, F# is very close to Ocaml, but has a healthier ecosystem for web stuff.
ReScript (formerly called ReasonML), is an interesting option for web apps (especially the front-end part), if you are interested in Ocaml-like languages.
Language-wise, it is Ocaml with a different syntax layer, so all of the nice things about the language are still available.
The language itself is very small and consistent and stable, and the community puts a higher value on getting things right than being consistent. So if there's a disagreement on the right way to implement something, you'll likely see multiple competing implementations, because people would rather implement their own library than use something they see as the wrong approach. Hopefully over the long term this means the best approach wins out and the ecosystem will converge on it, but with the small number of people involved this tends to be a slow process.
I get the distinct feeling that Ocaml’s leadership isn’t very interested in making a practical language, but rather playing with abstract type system ideas. Which is too bad because it clearly has a lot of potential. At this point, I think Rust will end up eating a lot of Ocaml’s potential market—Rust’s weakness is that memory management is harder than OCaml, but even that has become significantly easier between non-lexical lifetimes and rust-analyzer, and the pace of development of the Rust language is very fast while Ocaml moves like a glacier (still waiting on multicore!).
Well for example in the upcoming 4.12, the core team has integrated plenty of "practical" language features (such as support for iOS/OSX ARM64, or many changes related to multicore).
No doubt, but why are there still so many “standard” libraries? Where are is of the guides for building production applications? Why is the documentation so poor? How do the editor plugins compare to those for Go, Rust, etc? How familiar is the syntax to the broader body of developers? I’m not saying the Ocaml community never does anything practical; only that they don’t do enough to make their language mainstream.
And maybe they don’t want their language to be mainstream—that’s perfectly fine, but that undermines all of the arguments that this or that project should be (re)written in Ocaml or that Ocaml is otherwise a better language than $x for general software development.
> why are there still so many “standard” libraries?
There is one standard library--the one that ships with OCaml. You can use replacement libraries if you really need them--I haven't yet needed to, but for heavy-duty production use maybe one day I will.
> Where are is of the guides for building production applications?
Is the emphasis on 'building' here, as in 'build tool'? If so, then https://dune.build/ is what you need. If the emphasis is on 'production application', then I'm sure there are others but https://shonfeder.gitlab.io/ocaml_webapp/ comes to mind immediately.
> Why is the documentation so poor?
Which documentation specifically? If you mean OCaml itself, then you should check out https://ocaml.org/ , it has tons of high-quality documentation. If you mean third-party libraries, then it's probably mostly a lack of tooling that publishes docs automatically, but I think this is starting to change.
> How do the editor plugins compare to those for Go, Rust, etc?
The OCaml Language Server and its main editor plugin (for VSCode) are nearly feature-complete. The older Merlin tooling has been used for a long time.
> How familiar is the syntax to the broader body of developers?
Syntax can be learned, but for those who don't want to try, there is always ReasonML syntax that uses semicolons and curly braces to make OCaml look like JavaScript.
> I’m not saying the Ocaml community never does anything practical; only that they don’t do enough to make their language mainstream.
It's easy to make assertions without actually knowing anything, but it's better to do the research first to back them up, instead of asking a bunch of questions ;-)
> There is one standard library--the one that ships with OCaml. You can use replacement libraries if you really need them--I haven't yet needed to, but for heavy-duty production use maybe one day I will.
You're mistaken (or you're making an unrelated semantic argument because you don't want to argue the actual point; not sure which); there are multiple "standard" libraries used across the ecosystem (because the ecosystem has deemed "the one that ships with OCaml" to be inadequate) which makes integrating libraries throughout the ecosystem tedious and painful, especially to new OCaml developers.
> Is the emphasis on 'building' here, as in 'build tool'?
No, I expect an abundance of tutorials that explain how to build production-grade applications, soup to nuts. E.g., for a generic CRUD app, what are the best frameworks, ORMs, etc to use, how to integrate them, etc?
> The older Merlin tooling has been used for a long time.
Yes, but it's incredibly difficult to configure properly, or at least that was my experience when I got started. I'm actually not sure if I ever got it working with vim.
> Syntax can be learned, but for those who don't want to try, there is always ReasonML syntax that uses semicolons and curly braces to make OCaml look like JavaScript.
It can, but it's a burden with no advantage. Last I checked, ReasonML's support was pretty abysmal--it seemed like native compilation was neglected altogether in favor of something called "bucklescript" (presumably compilation to JS) and the integrations with the rest of the ecosystem (e.g., how to build native programs, link against ocaml dependencies, integrate with editor tools, etc) were either poorly documented or inadequate/incomplete or both. No doubt some of that has improved in the intervening years, but I'm doubtful that it has significantly improved.
> It's easy to make assertions without actually knowing anything, but it's better to do the research first to back them up, instead of asking a bunch of questions ;-)
You've provided the same unhelpful, pat answers that the OCaml community provides. For example, "Just use ReasonML!" as though setting up or using Reason is trivial or well documented or otherwise comparable to using Rust or Go out of the box. For another example, you altogether dodged the issues associated with multiple "standard" libraries. It would be great if the OCaml community were as committed to making their language useful for production applications as they were on convincing everyone else that it already was.
> as though setting up or using Reason is trivial or well documented
It's both trivial and well documented. There is an installation page and a tutorial on the Reason website. The installation in itself is one npm command.
> For another example, you altogether dodged the issues associated with multiple "standard" libraries.
There is only one standard library. It's the one shipped with the compiler. It is also significantly more battery included now than it used to be.
> It would be great if the OCaml community were as committed to making their language useful for production applications as they were on convincing everyone else that it already was.
The OCaml community as a whole is one of the least vocal on the internet. It does very little outreach. I never see any of the people I consider relevant to the community on HN for example.
No one cares about convincing you that OCaml is ready for production use. It doesn't need to be argued, it can just be shown. OCaml is not an up and coming language, it's a 25 years old one. It powers a lot of Jane Street infrastructure. It is used to develop Coq and Frama-C. It is transpiled to javascript at Facebook and Bloomberg. Heck, Rust which you apparently hold dear was originally written in it.
> there are multiple "standard" libraries used across the ecosystem (because the ecosystem has deemed "the one that ships with OCaml" to be inadequate) which makes integrating libraries throughout the ecosystem tedious and painful, especially to new OCaml developers.
OK, let's examine this a bit more. There is one (two, depending on how you look at it) main competitor to the OCaml standard library: Jane Street's Core/Base libraries. JSC is a high-quality, production-grade standard library replacement meant for use in applications. However it uses the same basic types (list, array, result etc.) as the OCaml Stdlib, so I don't see where your 'integration' issues are coming from. Can you give a specific example?
> No, I expect an abundance of tutorials that explain how to build production-grade applications, soup to nuts. E.g., for a generic CRUD app, what are the best frameworks, ORMs, etc to use, how to integrate them, etc?
OK, I provided one such tutorial in my previous comment. I'm sure more will come in time, as the community is still evolving. There is also the OCamlverse wiki which tries to distill a lot of community knowledge: https://ocamlverse.github.io/
> Yes, but it's incredibly difficult to configure properly, or at least that was my experience when I got started. I'm actually not sure if I ever got it working with vim.
If you use the community recommended Dune build system to run your builds, Dune generates .merlin files automatically. And if you use VSCode with the OCaml and Reason IDE extension, it picks up on those .merlin files and provides editor support pretty much out of the box. This has been the case for at least a couple of years now.
> ReasonML's support was pretty abysmal--it seemed like native compilation was neglected altogether ... and the integrations with the rest of the ecosystem (e.g., how to build native programs, link against ocaml dependencies, integrate with editor tools, etc) were either poorly documented or inadequate/incomplete or both. No doubt some of that has improved in the intervening years, but I'm doubtful that it has significantly improved.
It's been the case for quite a while now that Dune and odoc--two main tools in the OCaml toolchain--support Reason syntax out of the box. Again, if you are using Dune, you can use Reason syntax immediately, with no special setup. This is documented.
> You've provided the same unhelpful, pat answers that the OCaml community provides.
No, I've asked you to read the documentation and do your research before making claims. Not even Rust and Go are as 'trivial' to use as you make them sound. They have all had their editor support and library issues. OCaml maintainers and contributors are trying just improve the situation in OCaml just as much as their Rust/Go counterparts. But you have to meet them partway. They can't spend massive amounts of time marketing every single OCaml ecosystem improvement--otherwise they'd have no time to make the improvements.
I was just remarking to a coworker Friday how happy this made me; you get to write nice, obvious, readable string expressions with the right substitions, for ~arbitrary types.
The language however is quite nice and the stdlib is fairly complete.
Edit: Another problem I see is the (over?) reliance on PPX preprocessors. It does make a lot of tasks simpler, but it is too much magic for me personally.