Pain Points of OCaml

> Rust actually causes far more code churn - there's virtually a monthly cycle of some Rust compiler update requiring changes to existing code.

This is really surprising to me. Which changes have you had to deal with here? The only one I can think of is the major Edition 2024 upgrade, which changed the `#[no_mangle]` attribute to `#[unsafe(no_mangle)]`. But the old syntax still compiles just fine with the newest compiler using Edition 2021.

I stopped fighting this battle a long time ago. I think Ocaml just doesn't spoon feed people enough. They would have to actually read the documentation to understand and that's simply too hard nowadays so you end up which this kind of articles about "pain points" which are basically "I don't know what I'm doing and making a lot of mistakes, let me blame my tool".

Basically, when someone complaining starts by "I don't like the Algol-like syntax", obviously without saying it's Algol-like because that would require they actually know what Algol is, the rest is probably going to be extremely poor at best.

And here, it doesn't disappoint. Point 2, "I don't like type inference, it's too clever". Or you could just put type annotations at every declarations like every pieces of documentation ever produced on the language invite you to.

The type paragraph and the mentions of shadowing actually shows the author doesn't know how to use the Ocaml module system. For the neophytes here, it's the main standout feature of Ocaml. It's a bit like talking about C without knowing how to use pointers. I have seen people do that actually so I probably shouldn't be too surprised.

Menhir and ocamllex syntaxes are just slight twists on the actual syntaxes of yacc and lex. Nothing surprising for someone who knows both tools but I guess it's becoming a rarity nowadays. To be honest, the Ocaml compiler works exactly how you would expect a C compiler and linker to work. That makes it really simple and predictable for people who used to be C programmers but apparently completely inscrutable for young developers.

For printing, they quote "#[derive(Debug)]" in Rust but apparently they never reached ppx_deriving in Ocaml. It's a shame because it does exactly the same thing.

The whole conclusion with the weird segway about academics for a language which was purposefully designed to write provers and not as a research language doesn't even deserve to be commented upon.

Anyway, just go use Rust, bask in the hype, fight the borrow checker for things which don't require manual memory management, and leave us be. I think a significant part of why Ocaml is nice is that it is not appealing to many developers.

> OCaml's real pain point isn't the syntax - it's that you can't hire for it. if you're building a startup and you pick OCaml, you've just cut your hiring pool by 95%. that's way more painful than learning a different way to write functions.

I hear this a lot about Scala and it's never been an issue in practice.

A smaller pool of candidates makes hiring easier, I'd much rather screen 20 résumés than 400. The typical candidate, whether experienced or willing to learn, is also better on average.

"We can't find qualified developers" usually tells more about the employer, in reality that means:

- We aren't willing to pay market rates.

- We don't invest in even the most basic on-the-job training.

- Seniority distribution is junior heavy; we expect one senior developer per team who can mentor all the other ones.

Or a combination of the above.

I know two relatively small companies that use OCaml, they don't pay anywhere near Jane Street salaries, but they're willing to hire people who show interest in the language and invest a little in their training. This works. On my end I've hired several people coming almost purely from Python, after a few weeks they contribute to fairly advanced Scala codebases.

Nah. You have to change how you hire. You can’t do the “45 years OCaml experience required” thing. But you absolutely can hire for obscure languages.

> if you're building a startup and you pick OCaml, you've just cut your hiring pool by 95%. that's way more painful than learning a different way to write functions.

You can hire anyone who already understands pattern matching, closures, map/fold (these are more and more common constructs nowadays) and train them to learn OCaml. It's a simple language overall, especially if your codebase doesn't use any complicated features.

> OCaml in particular could do well with terminators after e.g. match blocks to improve both ambiguity and error reporting

You can use either begin/end or parentheses as terminators around any blocks of Ocaml for exactly that purpose.

> To me, the main downside of ML is the explicitly instantiated module systems not tied to the filesystem hierarchy.

That's one of the greatest strenght of ML actually and especially Ocaml where parametrised modules are everywhere and a required building block of generic code. A significant part of why the article complains about type for exemple is because the author doesn't know how to use the module system.

> Once you get used to traits and parameterised trait instances

I like modules a lot more. It makes the code a lot clearer than traits.

> The standard library situation is also somewhat not great. Maybe I just never got used to it, but I sense that there are people think Jane Street Base is a must

The standard library is a lot more complete nowadays that it was some years ago and Base is used by pretty much nobody outside of JaneStreet.

Not for me. I spent a few weeks a few weeks ago trying to use it. Much I liked. Much I didn't.

I like FP, so that was not a problem. But I found that lots of stuff was pretty hard for me as just an old guy trying to write some fancy little GUI apps to assist some of my other spare time activities. The project system, dune, was puzzling to me, and when I looked for clarification on-line it was pretty clear that I had lots of company. Not wanting to pass time writing code and seeing many potentialy useful packages available, I downloaded quite a few (actually, I downloaded not too many, but the dependencies required for those multiplied rapidly). Then I found myself managing multiple environments, because the different versions of this and that do not always work together so nice.

Some library code has to get imported some ways, some other ways. Etc, etc. Many tutorials teach the toplevel interpreter, but that's not recommended for projects of any size, and the other environments will choke on the code that works in the toplevel.

What I liked is that the OCaml ecosystem doen't look like it wants to control or ought to fear the next big thing. It's what you get when you have a lot of smart creative people who get inspired and do their best according to their own motivations and their own conception of quality. I admire that. I'm glad that I tried it.

I like the apology page.