I don't read this as "it was a mistake to use Pony." They state that:
> 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."
Mistake or not is hard to quantify without presenting what qualifies as success first. Is "it was able to achieve our initial goals" success or is "it was able to grow with our business" success? For each of those how much ability is enough to call it "not a mistake"?
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.
Wallaroo started as a company that was building high-performance data processing infrastructure for real-time trading and adjacent systems. Wordpress wouldn't really cut it.
For some startups, that makes sense, yes. For other startups, it may not. See pg's classic essay (that I'm not 100% sure I agree with, but, we're on hacker news) for one example of why you may want to use a more niche langauge: http://www.paulgraham.com/pypar.html
And Rails was extracted from Basecamp. I think startups depend so much on the few firsts individuals that it's hard to have a hard rule about what to use.
I think that might be more obvious today than it was five years ago? In 2016 rust was already ahead of pony in adoption, sure, but they were both young interesting languages. The five years since have widened the gap considerably in maturity (of the core language as well as community/ecosystem) I think.
Rust had Mozilla behind it, a well-known relatively large tech organization/corporation. Most, if not all, popular languages nowadays tend to have/had some backing behind them.
OTOH an interesting language can be a recruiting draw. It probably helped them recruit engineers who were interested in the distributed systems and concurrency problems they were trying to solve. See for example Jane Street with OCaml.
[edit: oops, thanks for the heads up on the spelling :)]
OCaml is old and reliable, and I think it was already proven to work in the industry when Jane Street chose it. Even if it wasn't the best programming language ever, it was still a strong choice at the time, and still is. Pony on the other hand was and still is very young. I'm not saying it's a bad choice, but it's definitely not the same risk profile as OCaml.
It's just OCaml by the way, for Objective Caml. Unless you're talking about the secret Irish fork /s.
> I think it was already proven to work in the industry when Jane Street chose it.
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.
> Outside of Jane Street OCaml has scarcely been proven to work in the industry now.
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.
I'm not sure, AoE2 taught me that camels always win against horses. And if you consider Rust to be OCaml's child (which is kind of true if you really stretch things), it seems like young camels win against young horses too.
There is a downside to using an interesting language as a recruiting draw; you are going to get people people who are more interested in the particulars of how you solve a problem than in actually solving the problem.
Sure, but if you take the time to actually read the article you'll learn that Pony was at the time the only language and runtime capable of meeting their needs.
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".
C++ and Java did exist, and rejected for the following reasons:
"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."
