[sanskarix]

what's always wild to me about these language debates is how much energy people spend defending syntax preferences instead of asking "does this help me ship?"

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.

the whole "academic vs practical" thing is backwards. academic languages often have killer features that would save you real pain, but if your team can't debug it or you can't find Stack Overflow answers at 2am, none of that matters. language choice is a business decision, not a technical purity contest.

[hocuspocus]

> 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.

[lo_zamoyski]

Indeed. The idea that increasing your hiring pool is good per se is like saying the best way to look for gold in California is to exhaustively sweep every inch of the state of California.

[yodsanklai]

> 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.

[cmrdporcupine]

It's almost certainly the opposite problem. You can't find a job in it.

There's a whole pool of people out there like myself who like to work in languages like this but don't because there's very few jobs in them.

When I heard people say they "can't hire for tech X" I usually find there's something else going on. I just left a job where they said they "couldn't hire" for Rust -- let me tell you... Finding Rust talent is not their problem. They have far more serious problems from which "retaining Rust talent" is a symptom.

The challenge with making good software is not language choice. It's communication and culture and making good foundational choices about software architecture that fit your problem domain. Writing code is the easy part, usually.

[christophilus]

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.

[yawaramin]

Here's a startup hiring for OCaml: https://terrateam.io/careers

What do you think their chances are?

[lawnchair]

We already made it. Thanks for the callout.

[yawaramin]

Sorry maybe ambiguous wording on my part, I meant 'what do you think their chances are of finding good candidates'.

[lawnchair]

Finding good candidates is easy.

[rixed]

I wouldn't hire someone who can't learn such a small and simple language in a week.

[cmrdporcupine]

I mean, the issue is not learning the language. It's the best practices, the standard libraries, the language idioms, etc. A week is a tad unreasonable.

A week to learn syntax? Sure. But to really be a fully operational battle-station engineer in a new language stack is probably 6 months to a year.

I would however expect people to be able to submit code reviews for e.g. bug fixes and small features after two to three weeks.

[rixed]

No really, that's a small ecosystem, we are not talking about Java or JS or python. Also, you should not need to know all the ropes of an ecosystem to work in one given environment.

If you are reasonably experienced with computers, learning the syntax will take you 2h. Again, that's Ocaml we are talking about. ML syntax has been designed to teach programming to fresh students with just a background in math.

If you already know C and Unix, you will be good to go in one afternoon... unless you want to use dune or compile to JS or use the repl etc.

[cmrdporcupine]

I taught myself both StandardML and OCaml 20+ years ago as hobby. But I'd never advertise myself as an OCaml programmer. Yes, the syntax is relatively easy to learn. But when I look at what Jane St etc have created for libs, the tooling, etc.

C'mon, there's more there than 2 weeks.

[rixed]

Ok but the amount of education that is needed to join Jane St is certainly very large, but acquiring the language itself is probably a very tiny amount of that. That's exactly why I'm disagreeing: there is much more to know and to learn than the syntax and semantic of a programming language to do a good job, that's why when I consider hiring I'm not insisting too much about previous familiarity with a given language; that's the easy part.

[cmrdporcupine]

yeah i think we broadly agree. Language syntax is the frankly lowest hurdle. Or should be. Knowledge of ecosystem and best practices and engineering wisdom is much more important.