> in the meantime data science and machine learning continued to explode ... With the increasing focus on MLOps, Rust became a better fit
This sounds like, "Our business goals shifted, as did the industry around data science, and Rust's maturity improved such that it made sense for us to migrate our stack."
I think it's fair to say looking back it was a mistake to pick Pony on the assumptions it provided marginal benefit for the exact needs of the business day 1 but at the same time I think it's fair to say that picking Pony was not a mistake as it allowed them to get where they are today.
Groupon was prototyped in Wordpress.
Ruby on Rails was created for Basecamp.
[edit: oops, thanks for the heads up on the spelling :)]
It's just OCaml by the way, for Objective Caml. Unless you're talking about the secret Irish fork /s.
There's a nice page on the official website about the history: https://ocaml.org/learn/history.html.
Not really. Outside of Jane Street OCaml has scarcely been proven to work in the industry now. As a big OCaml fan and former OCaml professional, I say this lovingly: it was (and remains) popular in academia and that's mostly it. And Pony is roughly as old now as OCaml was when Jane Street started using it.
The actual reason OCaml's risk profile was much lower was because it effectively has the backing of the French government and academy, which is quite the boon.
IIRC Jane Street chose OCaml basically because Yaron Minsky was brought on as CTO, he had worked with it in school and was a fan of it, and they knew that for the sort of work they were doing OCaml would give them an edge (speed of development and runtime efficiency) and they calculated that its relative obscurity and poor community support wouldn't be a liability for the sort of work they were doing. And remember that it was the year 2000 - Perl was basically the only language with the sort of library ecosystem (CPAN) that is expected of languages now: poor community support was much less of a liability then.
I think it depends on what you're working on. If you're building anything that looks like a interpreter/compiler, it's probably one of your best bets. If you're working on stuff that needs a lot of libraries, and relatively obscure ones, it's probably one of your worst bet. If you need good interaction with Windows, it's probably not a great choice either. The businesses I know, which are mostly SaaS, would probably fall under "not the best choice, use with caution". If that's the general case, I agree with you.
> The actual reason OCaml's risk profile was much lower was because it effectively has the backing of the French government and academy, which is quite the boon.
I wonder how much Jane Street benefited from that. The classes préparatoires are still using OCaml to this day (or at least were 3 years ago), and that's usually the best students of France. I've also heard that Facebook recruited quite a lot, for Hack and Flow.
> And remember that it was the year 2000 - Perl was basically the only language with the sort of library ecosystem (CPAN) that is expected of languages now: poor community support was much less of a liability then.
That's a good point. I think OCaml still has a better package manager and build tool than some really popular languages (I'm thinking specifically about Python), but it's hard to beat the ecosystem.
Ponies mature more quickly than horses, they are merely smaller.
https://www.thesprucepets.com/the-difference-between-horses-...
Unless you are in a dessert.
You'd also learn that this is a different product with different requirements.
There's no such thing as the "best language" - there's the "best language that fits your problem domain".
"Furthermore, the existing Apache tools depended on Java - specifically the JVM - where it's really hard to get predictable, very low latency results."
"From a purely performance perspective, C or C++ would have been a good choice. However, from past experience we knew that building highly distributed data processing applications in C/C++ was no easy task. We ruled out C++ because we wanted better safety guarantees around memory and concurrency."