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