Hacker News Reader

What about the risk of hiring schlubs who can watch enough Railscasts to duct tape things together, but don't know anything about writing solidly-engineered, maintainable code?

The hiring pool is absolutely swimming with these guys because demand for Rails developers is so high right now. You are more likely to find a better OCaml developer for cheaper than you can find an equivalently skilled Ruby developer just by virtue of being a place offering professional work in OCaml. To attract a similar caliber of Ruby developer you need to offer some crazy perks like sponsored open-source work or some really interesting problems which 90% of early-stage startups don't actually have.

You might think it's foolish to worry about the quality of code when you are just trying to rush to market, but as soon as you get to market you need to start iterating, and that's where you find yourself immediately saddled with technical debt. Worse—and I say this as a professional Ruby developer for nearly a decade—Ruby provides very little in the way of guarantees that developers won't do really stupid things. If you don't have a solid test suite you are dead in the water for maintaining a large app because the interpreter by itself gives you nothing. All those awesome libraries which exist for Ruby but not OCaml? The half-life on those things is like 18-months in the Rails community, meaning you are in constant maintenance mode to keep up with the flavor of the month or else face maintaining an old stack yourself once the original creators abandon it and the community moves on.

Not that this doesn't come with benefits, but you're overselling them to justify picking the modern no-one-ever-got-fired-for-buying-IBM choice compared to the risk of using something less well-known but certainly with critical community mass and much better maintainability characteristics.

People say functional programming is hard, but it feels just like a knee-jerk reaction. In practice, it doesn't seem to be much of an issue. For example, IMVU gave an experience report at BayHac about switching from PHP to Haskell; they found that onboarding a new employee (without significant Haskell experience) took about as much time as it did for their particular flavor of PHP (conventions, frameworks... etc)[1]. They found Haskell became much easier to teach given a strong set of opinions on code style and library choice.

Jane Street has had a similar experience with OCaml. In fact, they even teach all of their new traders—largely non-programmers—OCaml in a few months! [2] In fact, one of the main reasons they stuck with OCaml was because it made it easier for their domain experts to review and read code.

The same happens for hiring: it's not nearly as difficult as people seem to think. Sure, the supply is relatively low in absolute terms—but demand is even lower, proportionally! If anything, it's probably easier to hire quality developers in a language like OCaml because it serves both as a filter (applicants really self-select) as well as an additional perk to people interested in the language.

[1]: https://www.youtube.com/watch?v=gl3expkos4Q#t=483 [2]: https://www.janestreet.com/ocaml-bootcamp/

I've always been curious about Jane Street. It seems like a too-good-to-be-true story. Picking an obscure but powerful alternative to C++ and Java for a highly-competent core team makes sense, and has been done by several banks. But hacking OCaml does not fit the personality profile of (m)any traders I've met — most will happily whip up a spreadsheet to help their work, but writing extensive software and learning Hindley-Milner type systems falls outside their ordinary needs or interests.

You don't have to write extensive software or have a deep interest in type systems to use ML languages. You just have to know enough of the syntax to understand the API and write some functions to work with provided DSLs.

> learning Hindley-Milner type systems

Well, HM is about type inference and they can just assume it works correctly. And I don't think they are expected to write extensive, complex programs in the language but more put together pieces from their "vast trove of proprietary libraries", which are most likely designed just for the fact of faciliating the use of the language for users who are not (primarily) software developers.

I'm not sure you can realistically wire together pieces of functionality written in a statically typed language without understanding its underlying type system. Sure, by the time it compiles without errors the code probably needs less debugging than in a dynamically-typed language, but getting to that point can be difficult and frustrating. (Speaking from experience as a TA.)

> There is not a strong community behind OCaml. You can't take advantage of the numerous libraries and references created by the community like you can with Ruby, Python, Javascript, Java, or any of the other mainstream languages.

There certainly seems to be a strong community behind OCaml. There may be languages with stronger communities (but doesn't distinguish, particularly in individual domains, OCaml from the other languages you list.)

> OCaml is hard (and so are most functional programming languages).

Functional programming languages may be initially hard, compared to unfamiliar imperative languages, for people who have deep imperative programming experience. I don't see any reason to believe they are objectively hard, and plenty of people learn functional programming (even if not in a pure functional language) early on in their programming education and are familiar with it to a degree that functional programming languages aren't categorically difficult.

> OCaml is not popular. You will have to pay an additional premium for OCaml developers due to the lack of experienced talent.

This assumes that "not popular" means "low current supply" but not also "low current demand". If the benefits are underrecognized among firms, then the current supply of OCaml developers could well be underpriced compared to value.

> OCaml is a risk. If you're starting a consumer-oriented service, you need to prove there is a market for it. Will OCaml help you get to market faster?

Faster than what?

> I don't know. Will Ruby-on-Rails? Yes.

In the Ruby-on-Rails case, do you really know, are you just following accepted wisdom? What's the comparison "faster" against in the first place?

> I'd pick RoR any day just to eliminate the risk of getting to market late.

If RoR really could eliminate that risk, and had no other costs for doing it, that would be a no brainer. However, I don't see the basis for the concluding that that is genuinely and universally the case.

While your mileage will vary depending on the nature of your startup, I can point you to a paper we wrote summarising our experiences using OCaml to build the XenServer toolstack in a startup environment [1].

You should bear in mind that OCaml represents almost twenty years of continuous development (see the history chapter in Real World OCaml [2]), with a community steeped in some of the most cutting edge technology in modern programming languages (e.g. the Coq theorem prover or the CompCert certified C compiler).

I was the startup manager at XenSource that took the risk, and all of your points were not true for us:

- by joining the Caml Consortium (very cheap), we got access to the core developers and a yearly face-to-face. We're talking about Xavier Leroy and Damien Doligez here. Do you get that with Java?

- the compiler and runtime are utterly rock solid and engineered for a modern Unix environment. We found more serious gcc bugs (5+) than OCaml bugs (one, to do with compiling functions with >32 arguments, and was already fixed in trunk and a backport available inside a day).

- Hiring OCaml developers gave us the cream of the crop even for entry level jobs, and I work with several of the original team that we assembled to this day. See the paper [1] for details on several of the responses from within the company and how we responded.

- The OCaml community is very pragmatic, since the language is used in quite a few large codebases like Coq, CompCert, Why3, XenServer, Pfff (Facebook) as well as closed-source codebases such as Jane Street and Lexifi's. Most language evolution discussions are evaluated against these large users. I consider OCaml rather unique in that, despite being a small community, the ones that do use it do so seriously and often at scale.

I find it amusing that so-called "risk-averse" startup managers discount a 20-year old language with legendary stability in favour of relatively new languages. Nothing beats having developers that deeply understand their language and libraries, and that's only imparted with age and stability.

I would also note that being based in Cambridge, it's quite easy to grads that know ML (and the same is true in many US universities that teach OCaml, like Cornell, Harvard, Princeton and Yale).

[1] http://anil.recoil.org/papers/2010-icfp-xen.pdf

[2] https://realworldocaml.org/v1/en/html/prologue.html#a-brief-...

> I find it amusing that so-called "risk-averse" startup managers discount a 20-year old language with legendary stability in favour of relatively new languages.

While I mostly agree with your post, the four languages mentioned as opposed to OCaml in the grandparent post (Ruby, Python, Javascript, and Java) are all older than OCaml (which is 18 years old) -- Java, JavaScript, and Ruby are all 19 years old, and Python is 23 -- so they aren't "relatively new languages" compared to OCaml.

Yeah, although I guess it depends if you count Caml or not (1987). The intellectual history of the language can easily be traced back to 70s via the various LCF implementations, although the module system evolved significantly since then.

Either way, you're correct that all of these languages bear the proud scars of being tested for decades...

20 years for language X do not bring the same amount of benefits as 20 years for language Y, as can be clearly seen if we compare Javascript and OCaml.

Not sure which language looks better here... I'd say that even with its greater popularity, JavaScript is worse in pretty much every aspect than OCaml.

Yes, I meant OCaml looks better, in light of all the javascript traps.

by joining the Caml Consortium (very cheap), we got access to the core developers and a yearly face-to-face. We're talking about Xavier Leroy and Damien Doligez here. Do you get that with Java?

What do you find most useful about talking to core OCaml devs? If you were developing in Java, do you think you would see a similar benefit from talking to core Java devs?

How do you find the OCaml standard library compares to standard libraries from other languages? Is it expansive? Do you find yourself reaching for 3rd party libraries frequently (or writing your own)?

> What do you find most useful about talking to core OCaml devs? If you were developing in Java, do you think you would see a similar benefit from talking to core Java devs?

OCaml (and Java, and Python, and any other "old" language) evolves in small steps to avoid breaking existing code. A forum like this allows language developers making those design decisions to check them with big users, as well as to gather the qualitative feedback that only comes from trying to use a feature in a production system.

For example, OCaml's recent move in 4.02 towards immutable strings has generated a lot of debate [1] about the right tradeoffs to make with respect to backwards compatibility, and a number of the module system improvements such as module aliases have been driven by big libraries such as Core (to reduce compilation time and binary sizes).

> How do you find the OCaml standard library compares to standard libraries from other languages? Is it expansive?

I consider the OCaml "standard library" to actually mean the compiler standard library, since it really exists for the core toolchain to use. There are several alternatives that are one "open" statement away -- I've co-written a book about the Core library (see https://realworldocaml.org) for instance, which is extremely expansive. The OPAM package manager makes it trivial to use third-party packages now (http://opam.ocaml.org), so the distinction between standard library or not is pretty moot now.

> Do you find yourself reaching for 3rd party libraries frequently (or writing your own)?

I've written my own operating system in OCaml, so I'm possibly the wrong person to ask about that...

[1] http://blog.camlcity.org/blog/bytes1.html

Java has JCP.

Fully agree, doing what everyone else is doing is not managing risk, it's just taking on the same risk as everyone else.

But there is a strong community behind OCaml. A lot of undergraduate programs use a dialect of ML for their core classes.

While most OCaml implementations have poor standard libraries, Jane Street Capital has released several open source libraries that make it easy to implement high quality, performant applications.

> But there is a strong community behind OCaml. A lot of undergraduate programs use a dialect of ML for their core classes

I don't understand your response. Are you saying the OCaml community primarily consists of undergraduates?

> While most OCaml implementations have poor standard libraries

That right there should tell you something.

>I don't understand your response. Are you saying the OCaml community primarily consists of undergraduates?

What I am saying is that a sizable portion of academia uses a variant of ML. Maybe it hasn't caught on in industry, but that doesn't mean that there isn't a community that uses it.

> That right there should tell you something.

A lot of development of core tools for mainstream languages comes from the companies that use them. Clang and LLVM, for example, received support from Intel, Google and Apple just to name a few.

Jane Street has reimplemented much of the OCaml standard library for their own purposes. Facebook has already started implementing tools in Haskell. Once functional languages gain more traction, I suspect that the tools will improve substantially.

Not really disaggreeing with you but,

> What I am saying is that a sizable portion of academia uses a variant of ML. Maybe it hasn't caught on in industry, but that doesn't mean that there isn't a community that uses it.

Academic communities tend to be scattered when it comes to software and the primary focus is on publishing papers rather than producing software that is useful to others. Also, I know a number of skilled academics that use functional languages, but they tend not to have an interest in changing into the industry, rather stay at university. So I wouldn't depend on them as source for recruiting.

Of course there are exceptions, e.g. OCaml Labs seems to be keen on producing well-written, usable software that can be used in industrial settings. The development of Mirage is a pretty exciting area.

Yeah. The movers and shakers in software are always the big companies. But there are quite a few institutions that feature functional programming in their undergraduate curriculum.

One of the main gripes that people mention with functional languages is that it can be difficult to find developers. Several good universities are pouring out competent programmers.

>> While most OCaml implementations have poor standard libraries

> That right there should tell you something.

I wouldn't use that as the main criteria to judge a language. C has a poor standard library (for a definition of "poor" relative to, say, python) and so does C++. But they are certainly useful tools in their domains.

In any case, OCaml has a couple of standard library replacements/augmentations that reduce the gap a bit. (Batteries Included [1] and Jane Street's Core [2])

[1] https://github.com/ocaml-batteries-team/batteries-included/

[2] https://github.com/janestreet/core and https://github.com/janestreet/core_kernel

I think it comes down to if your company has strong enough technical leadership to retain an ocaml engineering team. If there is dissonance between how engineering thinks about the business and how the leadership thinks about the business, you'll not reap the benefits of ocaml and the team will leave. In practice I think this means the founding team has to have an ocaml expert for ocaml to work (or any other not-mainstream tech choice). You can't just hire one and hope for the best.

You speak of "the business case" as if there is only one kind of software business in the world, one that focuses on getting to market quickly with inexpensive developers. Reasons like "OCaml is hard" are short-sighted unless you are only planning for the short term. You wouldn't have to hire for OCaml, just for functional programmers.

That's stupid - all software businesses are (or at least should be) focusing on getting to market quickly, and there's no justification for the view that "a swarm of middling developers" is commonplace.

Parent was worried about availability of OCaml developers, and would "pick RoR any day just to eliminate the risk of getting to market late." Never mind that RoR is a web framework, this kind of thinking, that some technology is a silver bullet, or that another is unusable because it is less popular, or that six so-so developers are worth as much as two or three good ones because they're easier to find, is a real problem. It's immature to say out-of-hand that some language, for any application, is "too risky" when it has a good industry track record.

I was trying to write an eloquent reply but I remembered that PG did a better job than I could.

http://www.paulgraham.com/avg.html

and especially this:

"when you're writing software that only has to run on your own servers, you can use any language you want"

Having substantial experience running a startup on Scala (Not OCaml, but many of the same aspects apply) I'm going to throw my 2c in.

> There is not a strong community behind OCaml. You can't take advantage of the numerous libraries and references created by the community like you can with Ruby, Python, Javascript, Java, or any of the other mainstream languages.

You'd be surprised how good the community is around FP languages.

> OCaml is hard (and so are most functional programming languages)

I'm going to strongly disagree on this one. FP is different to what you're used to. Once you've learned it I actually think FP is substantially easier, especially when maintaining large codebases. The amount of cognitive effort required to write code in an FP style is substantially lower.

> You will always need exceptionally talented developers to work on your code base and that will get expensive

I work with Scala, not OCaml personally, but I've been able to train Junior Java devs up on Scala (In a pure-fp style) with minimal effort. In addition, I find there's a very large talent pool of excellent developers wanting to work with FP in a commercial environment, and are willing to work for less for the opportunity.

Hiring has actually been substantially easier since I switched to Scala, and I'm getting better developers for less.

> OCaml is a risk. If you're starting a consumer-oriented service, you need to prove there is a market for it. Will OCaml help you get to market faster? I don't know. Will Ruby-on-Rails? Yes. I'd pick RoR any day just to eliminate the risk of getting to market late.

I'm sure people were saying the same thing about PHP vs RoR back on the day.

Any new technology is a risk if you're new to it.

For those that have taken the 'risk' of using an FP language, the payoff has been worth it. From my experience with FP Scala, the go to market time has been substantially quicker than with any other platform I'd used previously. The defect rate has been 90%(!) lower, productivity is higher, the codebase is easier to work on, an it's easier to find top-tier developers.

Mind you I can understand not wanting to bet the farm on it from day one - this is why Scala was an easier choice for us, because we could fall back to Java if we have problems (We didn't).

I think the issue is expressive power, since FP languages have more power people find them daunting, like calculus, however, like calculus once you understand it many formerly complex problems are quite simple.

The fact that OCaml is not an easy language might be a good way to find great developers.

It is. For the most part, the developers who use an esoteric language and understand it's benefits are usually of higher skill that your average developer, and those who are excited enough about it to want to work in it are usually even better still. It's the whole "Beating the Averages" thing that PG talks about. There are risks, but they can be managed, and the benefits are great if you know what you're doing!

I often hear how using how using less mainstream and more difficult to learn (as in requires some mind warping if coming from more mainstream language) languages acts as a filter that will leave more capable programmers to choose from, even if there are less of them.

Does anyone know if there have been studies to back this up? Or studies that back up the above comment.

My experience is that programmers who enjoy warping their minds with something different tend to be more capable, or at the very least, up for a challenge. Would be nice to see something else than anecdotes.

I would agree that in my personal experience, those people do tend to be quite intelligent. However, I have not found them to be more productive (and in some cases, they seem to be less productive, because they spend so much time fiddling and tweaking instead of just finishing things).

This is similar to the PhD filter. You have to find folks who have the right balance between theory and practice.

>There is not a strong community behind OCaml. You can't take advantage of the numerous libraries and references created by the community like you can with Ruby, Python, Javascript, Java, or any of the other mainstream languages.

For a project of moderate-to-high complexity, the advantage I gain as a developer by using a more powerful, if more esoteric language, hugely outweighs the time I spend building tooling/libraries etc..

RoR et al might win out for low-complexity projects, but as the project grows the power of the language quickly eclipses the advantages of pre-existing libraries and easy-to-find "talent".

>You will always need exceptionally talented developers to work on your code base

You should strive to hire these people anyway!

This is another non-issue, if you're hiring The Right Way: hiring smart people. I just started a job writing Java having never written Java before in my life (coming from a background in Perl, JS & Erlang), and in a previous position picked up Erlang on-the-job. It's pretty much a non-issue if you hire talented engineers.

Basho's experience with Erlang illustrates these points well: http://basho.com/erlang-at-basho-five-years-later/

> Will OCaml help you get to market faster? I don't know.

They know, this article is basically them explaining that they feel ocaml gives them a competitive advantage. PG said the same thing about viaweb using Lisp vs. Perl/C+CGI