OCaml has been one of those "almost there" languages since at least 2002. Most of the worthwhile ideas in OCaml will be absorbed into more popular languages by the time existing friction is sorted out. :/
> Our hope is that these extensions can over time be contributed to upstream OCaml.
Yeah, its more just extensions to support their use cases at scale. Think of it more as bleeding edge ocmal, once they work out kinks/concerns they'll get merged back into the language OR if it remains ultra specific it'll stay in oxcaml.
Python gets forked in other investment banks as well. I wouldn’t say that is evidence of any deficiencies, rather they just want to deal with their own idiosyncrasies.
A different perspective is that JS has made practical application of PLT part of their secret sauce, and deepening into their PLT roots is thickening the sauce.
The main user has been writing extensions to the compiler that they test before pushing for integration like they have done for the past twenty years or so. They publish these versions since last year.
Hardly a failure and certainly not something mandatory to keep things from failing over. Your initial comment is extremely disingenuous.
This is the wrong interpretation of the oxcaml project. If you look at the features and work on it, it's primarily performance or parallelism safety features.
The latter going much further than most mainstream languages.
Yeah, but when these things happen I ask myself, is Jane Street successful because of ocaml, or did they just happen to pick ocaml and then make it work?
There might be some power in attracting all the people who happen to love ocaml, if there are enough of competent people to staff your company, but that's more a case of cornering a small niche than picking on technical merits
They've spoken about this before and might not have picked OCaml if they had to make the decision again today. I think at the time it made the most sense.They can also make it work in any language as they claim to only recruit the best and brightest in the world (this may be the truth). My opinion is they could have chosen many languages and had similar results while balancing different trade-offs.
Regarding attracting talent, they've said they don't care about existing knowledge of OCaml as the language part is something they train staff on anyway. Their interviews are brutal from what I recall. I could be an OCaml expert and have no chance of making it through an interview without equal talent in high performance fintech and relevant mathematics.
> I could be an OCaml expert and have no chance of making it through an interview without equal talent in high performance fintech and relevant mathematics.
Unless their hiring process has changed in the past few years, if you're a dev they're not hiring you for your financial skills, just general problem solving and software development ability. It is (was?) the usual Google-style algorithms/data structures rigamarole, but somewhat more challenging.
Do those devs actively use OCaml? I thought most of the folks writing OCaml were writing the actual trade algorithms as opposed to infrastructure folks. My post was made off what I recall their lead technologist saying.
Absolutely. Everyone uses OCaml at Jane Street; pretty much everything at Jane Street is OCaml. If an OCaml version of something doesn't exist, there's a decent enough chance that they'll write it themselves rather than resort to a non-OCaml solution.
Like I said, my information might be a hair out of date, but it's first-hand.
Gotcha. Mine is just some old blog posts and a long talk from the guy that got OCaml started. Nothing like your actual first person experience. Thanks for adding!
Unless you're building another JS, it'd be nice if there were other companies so heavily invested in it. There's a lot out there beyond compiler prototypes and high speed financial trades, but there's not enough talk of people using ocaml for those things.
Ocaml was (historically, at least) used by Facebook for basically all of their linter/compiler/type checker work. The hack checker was in Ocaml, as was the JS thing (flow, maybe?).
So that does seem to be a good use-case for the language.
That was why I mentioned compilers along with HFT. Rust was originally an ocaml based compiler too.
I don't build HFTs and my compilers are just for fun. None of my day jobs have ever been a situation where the smaller ecosystem and community of ocaml was offset by anything ocaml did better than the selected options like .net, Java, go, rails, C or anything else I've touched. Heck, I've written more zig for an employer than ocaml, and that was for a toy DSL engine that we never ended up using.
Because plenty of people have been shipping great projects in Ocaml since it was released so it doesn’t seem to be much of an issue to many.
I doubt Ocaml will be surpassed soon. They just added an effect system to the multicore rewrite so all things being considered, they seem to be pulling even more ahead.
Beginners face the following problems: there's multiple standard libraries, many documents are barely more than type signatures, and data structures aren't printable by default. Experts also face the problem of a very tiny library ecosystem, and tooling that's often a decade behind more mainstream languages (proper gdb support when?). OCaml added multicore support recently, but now there is the whole Eio/Lwt/Async thing.
I used to be a language nerd long ago. Many a fine hour spent on LtU. But ultimately, the ecosystem's size dwarfs the importance of the language itself. I'm sympathetic, since I'm a Common Lisp man, but I don't kid myself either: Common Lisp isn't (e.g.) Rust. I like hacking with a relic of the past, and that's okay too.
TBH I think it's rather a post-hoc rationalization of why the language is not popular.
> there's multiple standard libraries
Scala has a far more fragmented ecosystem with Cats, Scalaz, Zio and Akka. C++ and Java have a bunch of stdlib extensions like boost, Guava, Apache Commons etc.
> many documents are barely more than type signatures
Can be said of most of Java, Kotlin, Scala, Erlang etc etc. Just compiled javadocs, sometimes with a couple of unhelpful lines.
> data structures aren't printable by default
Neither they are in C++
I think the real reason it's not popular is that there are languages which solve more or less the same problems of system programming but look far more familiar to an avg. programmer who was raised on C++ and Java.
I wanted to use OCaml since 2002, since it was a GC'd language with good performance, achieving a lot with relatively few lines of code. Being a language nerd, I was (am?) positively inclined to the language. Yet there was always something that made it notably less pleasant to solve my current problem in than in than some other language.
If it had trouble getting traction with me, that's bad news.
Meanwhile the mainstream has progressed a lot since 2000. GC is the standard, closures are normal, pattern matching and destructuring are increasingly so. While HM-style type inference is not mainstream, local type inference is (and I'm no longer convinced that global type inference is the way). Algebraic data types aren't unusual anymore.
A few years back I just threw in the towel and went with Rust; this happened after I volunteered to improve OCaml's gdb support (including DWARF hell), which went nowhere. I wish Rust compiled faster, and a GC'd language is usually more productive for my problems, but in every other regard it stole what should have been OCaml's thunder. And when popular successor languages eventually appear, they'll do it even better.
Pony's garbage collection and runtime can
yield performance faster than C/C++/Rust because
the compiler eliminates data races at
compile time, and thus no locks are needed.
It features implementations of Dmitri Vyukov
(www.1024cores.net) algorithms for
work stealing and Multi-producer single
consumer queues that use only a single atomic
instruction to read. The designer,
Sylvan Clebsch, is an ex-game-developer and
ex-high-frequency-trading-infrastructure
engineering lead; he knew what he was
doing when he designed the language
for high performance on multicore systems.
On the other hand, you do have to re-wire
your thinking to think in terms of Actors
and their state, and this is kind of hard
to wrap one's head around if you are used
to Go's CSP or the popular async/await
approaches -- it is a somewhat
different paradigm.
You probably know it, but Common Lisp May be a bit dated but it’s extremely modern in terms of features since you can add almost any feature to the language in libraries! I use it exactly because it’s old and battle tested and I don’t need to wait years for a language designer to give me a feature , I can just add it myself, though these days it has everything done already!
There is only one standard library and it shipped with the compiler.
> data structures aren't printable by default
So? That’s the case with most languages. Ocaml has a deriver to make types printable and a REPL which automatically prints for testing.
> tooling that's often a decade behind more mainstream languages
Opam is a fully featured package manager, dune works fine, bucks2 supports Ocaml.
> proper gdb support when?
Ocaml has had a rewindable debugger since approximately forever.
> OCaml added multicore support recently, but now there is the whole Eio/Lwt/Async thing.
Lwt was the default and everyone agrees eio is the future now that effects are there. Async is a Janestreet thing with pretty much no impact on the language outside of Janestreet.
Honestly, I maintained my initial point. Ocaml alleged frictions were always widely overstated.
When I was writing Ocaml professionally 15 years ago, there was no dune and no opam and it was already fairly easy to use the language.
Rocq is an excellent example of something OCaml was designed for. FFTW3 is another great example. Unison too.
Generally, you want stuff where you have to build a fairly large core from scratch. Most programs out there doesn't really fit that too well nowadays. We tend to glue things more than write from nothing.
Rocq, Pfff and Flow, Vpnkit in Docker for Mac and Windows, the web version of Facebook Messenger at a point, Tezos, Unison, the Xen cloud platform, the Mirage unikernel.
