The Janet Street folks, who created this, also did an interesting episode[0] of their podcast where they discuss performance considerations when working with OCaml. What I was curious about was applying a GC language to a use case that must have extremely low latency. It seems like an important consideration, as a GC pause in the middle of high-frequency trading could be problematic.
I actually asked Ron Minsky about exactly this question on Twitter[0]:
Me: [W]hy not just use Rust for latency sensitive apps/where it may make sense? Is JS using any Rust?
Minsky: Rust is great, but we get a lot of value out of having the bulk of our code in a single language. We can share types, tools, libraries, idioms, and it makes it easier for folk to move from project to project.
And we're well on our way to getting the most important advantages that Rust brings to the table in OCaml in a cleanly integrated, pay as you go way, which seems to us like a better outcome.
There are also some things that we specifically don't love about Rust: the compile times are long, folk who know more about it than I do are pretty sad about how async/await works, the type discipline is quite complicated, etc.
But mostly, it's about wanting to have one wider-spectrum language at our disposal.
Well on their way.. by having to write a ton of C for the interpreter. I think it’s really imprudent for them not to be using Rust yet for critical sections.
The knobs aren't on the GC necessarily, rather language features.
With a Go compiler toolchain you have stack and global memory static allocation, use of compiler flags to track down when references escape, manually allocate via OS bindings, there is the unsafe package, and use slices with it, an assembler is part of the toolchain learn to use it, and regardless of CGO is not Go memes, it is another tool to reach for if Assembly isn't your thing.
Ohh right yes, now I get what you mean. My brain just immediately went for "GC knobs" when you mentioned "knobs", but in my defense I'm running a 40°C fever so I should probably not be commenting at all
GC compactions were indeed a problem for a number of systems. The trading systems in general had a policy of not allocating after startup. JS has a library, called "Zero" that provides a host of non-allocating ways of doing things.
I was bit by the same spider that gave you web tunnel vision. In any case, I find OCaml too esoteric for my taste. F# is softer and feels more..modern perhaps? But I don’t think GC can be avoided in dotnet.
> This is what I like to call a dialect of OCaml. We speak in sometimes and sometimes we gently say it’s zero alloc OCaml. And the most notable thing about it, it tries to avoid touching the garbage collector ...
> What I was curious about was applying a GC language to a use case that must have extremely low latency. It seems like an important consideration, as a GC pause in the middle of high-frequency trading could be problematic.
Regarding a run-time environment using garbage collection in general, not OCaml specifically, GC pauses can be minimized with parallel collection algorithms such as found in the JVM[0]. They do not provide hard guarantees however, so over-provisioning system RAM may also be needed in order to achieve required system performance.
Another more complex approach is to over-provision the servers such that each can drop out of the available pool for a short time, thus allowing "offline GC." This involves collaboration between request routers and other servers, so may not be worth the effort if a deployment can financially support over-provisioning servers such that there is always an idle CPU available for parallel GC on each.
You just let the garbage accumulate and collect it whenever markets are closed. In most cases, whenever you need ultra low latency in trading, you usually have very well defined time constraints (market open/close).
Maybe it's different for markets that are always open (crypto?) but most HFT happens during regular market hours.
No, compared to not doing so many allocations that freeing them is time consuming or expensive. Having allocations slow a program down means that there are way too many, probably due to being too granular and being in a hot loop. On top of that it means everything is a pointer and that lack of locality will slow things down even further. The difference between allocating many millions of objects and chasing their pointers and doing a single allocation of a vector and running through that can easily be 100x faster.
Probably? Locality becomes fairly important at scale. That’s why there’s a strong preference for array-based data structures in high-performance code.
If I was them I’d be using OCaml to build up functional “kernels” which could be run in a way that requires zero allocation. Then you dispatch requests to these kernels and let the fast modern generational GC clean up the minor cost of dispatching: most of the work happens in the zero-allocation kernels.
I think it is, but to be clear I think (from my very limited experience, just a couple of years before leaving finance, and the people with more experience that I've talked with) that c++ is still a lot more common than any GC language (typically java, since OCaml is even rarer). So it is possible, and some firms seem to take that approach, but I'm not sure exactly how besides turning off GC or very specific GC tuning.
Here is a JVM project I saw a few years back, I'm not sure how successful the creators are but they seem to use it in actual production. It's super rare to get even a glimpse at HFT infra from the outside so it's still useful.
Are you aware of how many allocations the average program executes in the span of a couple of minutes? Where do you propose all of that memory lives in a way that doesn’t prevent the application from running?
Haven't looked at the link, but I think for a scenario like trading where there are market open and close times, you can just disable the GC, and restart the program after market close.
Anonymous labeled structs and enums are some of my top wished-for features in programming languages! For instance, in Rust you can define labelled and unlabelled (i.e. tuple) structs
In Dart, we merged tuples and records into a single construct. A record can have positional fields, named fields, or both. A record type can appear anywhere a type annotation is allowed. So in Dart these are both fine:
The curly braces in the record type annotation distinguish the named fields from the positional ones. I don't love the syntax, but it's consistent with function parameter lists where the curly braces delimit the named parameters.
The syntax is a little funny for mostly historical reasons. The curly braces are only part of the record type syntax. There's no ambiguity there because curly braces aren't used for anything else in type annotations (well, except for named parameters inside a function type's parameter list, but that's a different part of the grammar).
they're not asking for a structural typing overhaul, just a way to make ad-hoc anonymous types with named fields and pass them around. a lot of times with tuple return types you're left wondering what that random `usize` is supposed to represent, so having names for it would be very convenient. i don't see why, under the hood, it couldn't just be implemented the exact same way as current tuple return types
> they're not asking for a structural typing overhaul, just a way to make ad-hoc anonymous types with named fields and pass them around.
And their point is that the two boil down to the same thing, especially in a non-trivial program. If switching field positions around changes their semantics, tuples may well the most sensible choice. As for "what that random usize is supposed to represent" that's something that can be addressed with in-code documentation, which Rust has great support for.
Also, if it's not just a "random usize" then you should use the new type paradigm. In a language like Rust that's not quite as smooth as it could possibly be, but it's transparent to the machine code. Rust's Option<OwnedFd> is the same machine code as C's int file descriptor, but the same ergonomics as a fancy Haskell type. We can't accidentally confuse "None, there isn't a file descriptor" for an actual file descriptor as we so easily could in C, nor can we mistakenly do arithmetic with file descriptors - which is nonsense but would work (hilarity ensues) in C.
If these aren't "random" usizes but FileSizes or ColumnNumbers or SocketTimeouts then say so and the confusion is eliminated.
It's interesting that languages which start with purely nominal structs tend to acquire some form of structurally typed records in the long run. E.g. C# has always had (nominally typed) structs, then .NET added (structurally typed) tuples, and then eventually the language added (still structurally typed) tuples with named items on top of that.
I think the main dividing line here is whether you want to lean into strict typing or whether you prefer a more loose typing structure. The extremes of both (where, for instance, the length of an array is part of its type definition or there are not contractual guarantees about data) are both awful. I think the level of type strictness you desire as a product is probably best dictated by team and project size (which you'll note changes over the lifetime of the product) with a lack of typing making it much easier to prototype early code while extremely strict typing can serve as a strong code contract in a large codebase where no one person can still comprehend the entirety of it.
It's a constant push and pull of conflicting motivations.
> Because sum:int * product:int is a different type from product:int * sum:int, the use of a labeled tuple in this example prevents us from accidentally returning the pair in the wrong order, or mixing up the order of the initial values.
Hmm, I think I like F#'s anonymous records better than this. For example, {| product = 6; sum = 5 |}. The order of the fields doesn't matter, since the value is not a tuple.
One reason why they're not the same is because the memory representation is different (sort of). This will break FFIs if you allow reordering the tuple arbitrarily.
Oh I see, good point. I'm wondering how this is represented internally. Fields alphabetically? I've also desired extensible anonymous structs (with defaults) from time to time, but implementing that would involve some kind of global analysis I suppose.
Labeled tuples are effectively order-independent. Your implementation's order has to match your interface's order, but callers can destruct the labeled tuples in any order and the compiler will do the necessary reordering (just like it does for destructing records, or calling functions with labeled arguments). I don't think this is materially different from what you're describing in F#, except that labeled tuples don't allow labeling a single value (that is, there's no 1-tuple, which is also the case for normal tuples).
I wasn't aware that this fork supported SIMD! Between this, unboxed types and the local mode with explicit stack allocation, OxCaml almost entirely replaces my past interest in F#; this could actually become usable for gamedev and similar consumer scenarios if it also supported Windows.
Yeah, this would be great! Currently only 128-bit SSE/NEON is working but AVX is coming very soon. There's also nothing blocking Windows, but it will require some work. (I added the SIMD support in OxCaml)
FWIW, the "Get OxCaml" page actually says that SIMD on ARM isn't supported yet. If it actually works it would be worth removing that from the known issues list https://oxcaml.org/get-oxcaml/
Cool to hear there aren't any technical blockers to add Windows support! You just convinced me into giving OxCaml a try for a hobby project. 128-bit SSE is likely to be enough for my use case and target specs.
Because alerts are promoted to errors, they break existing package installs unnecessarily. The OCAMLPARAM environment variable just forces that alert to be disabled and allows the package installation to continue.
Probably spoilt here but being used to the excellent vscode plugin (well vscodium in my case) for Golang but... any plans to integrate with vscode ecosystem? Makes setup so straightforward!
The OCaml vscode plugin seems to have already integrated a lot of new syntaxes (dune, menhir, reason), so if OxCaml gains traction it should only be a matter of time.
(can't really speak for that myself, though, I use emacs)
If you follow the installation instructions on oxcaml.org, you’ll get a patched Merlin with LSP support etc. It’s not perfect, but does mostly work out of the box with VSCode and the OCaml Platform extension.
Error squiggles and ocamlformat stopped working for me after the first time I restarted VS Code, compared to regular OCaml. They do work fine through the Dune CLI though.
Did you change the opam switch that vscode extension uses? It needs to be set to the oxcaml switch - you can do this via the "Ocaml: Select a Sandbox for this Workspace" command.
Yes I did, I'm used to working with opam, and when I first changed the switch it worked until I restarted VS Code. But since then I haven't managed to make it work again.
I had a similar thought to this, but then I thought, who is worse: programmers who keep bloating up existing languages with new features, or programmers who create yet another new language to add to the already crowded field? (I'm in that latter category.)
I guess programmers are just genetically incapable of leaving their tools the way they are.
What are the chances that they are releasing this so that LLMs can index this information for free and they can use public models in their codebase rather than finetuning public models?
Given how poor LLMs are at regular OCaml, which has so much more training data that OxCaml, probably none. An MCP for docs would have been more productive for that purpose.
Not good at all. It's not a strong enough signal. For instance, LLMs are absolute dogshit at completing Gleam, even if given files with the exact pattern they need to mimic just lines away, or given explicit instructions on common mistakes it makes.
So this is "oxidized" because it tries to achieve the same features as Rust (e.g. "fearless concurrency" is mentioned, and avoiding GC)... Not because it actually uses Rust in any way right? Slightly confusing.
Yes, they've used this terminology for a while, even the recent technical paper on this effort was titled "Oxidizing OCaml with Modal Memory Management", though the word "oxidize" itself is never actually referenced or defined in the paper. A bit strange, I agree, though it's kind of catchy I admit.
Rust will probably become usable with custom tracing GCs (which is helpful if you're dealing with general graph-like data but still want the highest performance as far as practical) way before this effort reaches genuine feature parity with Rust. Not seeing much of a point in this, unless they perhaps intend to focus on the lowest-hanging fruit and have big O(x)Caml codebases that they care about.
OxCaml takes a different approach to encoding locality to Rust. Rust (arguably) overburdens the type-system with this information whilst in OxCaml this is orthogonal to the return types. In that sense it's a bit like algebraic effects. Personally I'm quite bullish on OCaml these days.
OCaml is a good language and these extensions are very welcome to existing OCaml programmers and programs, as well as many of the other extensions Jane Street has added. I don't understand what you mean here.
Your comment remains completely stupid regardless of how much of it is in the quote. OxCaml's goal is to be upstreamed. "I don't see the point in this unless people have programs using OCaml" and it's like, yeah, that's the point of adding features to a computer program. Any computer program. Because people already use the computer program and it will be useful to them.
I actually see this as an escape opportunity for F#-ers. I love the language, but the runtime and C# ecosystem are not only holding it back from having cleaner semantics (until the C# team sees the value in them), they've been actively kicking it down the ladder with breaking changes and new incompatible APIs.
Fable is the complete opposite direction to .NET and OxCaml, though. Nice for people doing web I guess (I'd rather do TypeScript than deal with interop), but the JS runtime and ecosystem are pretty much useless for my use cases.
Maybe a pure WASM target could actually liberate F#.
Why? They have one of the largest Ocaml codebases in the world. It has clearly work out VERY well for them, in terms of productivity and pure ROI in features and revenue.
Ocaml has so much good going on, even being a less known language.
I assume you are a rust fanboy, and i want to see just how long your smirk holds when you compile a 20M LOC project that takes 45 minutes.
I've never written a line of Rust in my life, but I unfortunately had the great displeasure to write OCaml.
OCaml is a terrible choice for (anyone) a company like this. They NEED to be able to hire the very best of the best, but choosing an exotic language that is less palatable than a plate of shit and more cryptic than alien hieroglyphs restricts your talent pool A LOT.
I'm not saying people cannot learn it, I'm saying people won't want to, for multiple very good reasons (it sucks, it's not at all transferable skill, etc.).
>They NEED to be able to hire the very best of the best,
This is literally why they've chosen Ocaml. Yaron Minsky has often stated that interest in a language like this is effectively a filter and magnet for extremely smart and curious people, he credits Ocaml with being an advantage in that regard.
They don't care about transferable skills either. People at Jane Street earn hundreds of thousands per year starting out, virtually nobody ever leaves, you're set for life after a decade there.
Aso Ocaml is a pretty standard ML. If you think it's unreadable alien hieroglyphs its fair to say you're not the demographic they're trying to attract, so the system is working.
Thats BS. I have learnt Ocaml and im far from "the best if the best". Its just syntax in the end, took me a few weeks to get productive enough to ship features.
Rust on the other hand, takes usually way longer to grok, mostly because of its borrow checker that is quite unique to rust.
The implication here, I think, is that "Jane Street has foolishly invested heavily into Ocaml and, rather than sensibly change course and migrate away, they continue to invest heavily into it in the hopes that one day the investment will pay off."
Which is a ridiculous take: Jane Street has done extraordinarily well for themselves, possibly at least in part because of their investment in Ocaml, and any sort of migration would be a huge undertaking, and an absurd and unnecessary risk.
I do think Jane Street fell into a sunk cost fallacy when they first stuck to OCaml. But after having invested further into an OCaml/OxCaml codebase, teams and tooling, switching tech stacks has lost most of its value.
Also, their efforts benefit me greatly as an OCaml (now maybe OxCaml) user, so I'm glad they took that path.
I dunno. Jane Street started using OCaml back in 2002. Consider the world of programming languages back then: no Rust, of course...but, like Java wouldn't even have generics for another two years! At the time - and for a long time after - OCaml's offering of power/performance was pretty unbeatable. It arguably still is, but I think there's at least an argument these days. I'm not sure exactly when that argument became viable, but it would've been long-after Jane Street had already built up a pretty huge codebase and a pretty crack team of OCaml engineers.
The Janet Street folks, who created this, also did an interesting episode[0] of their podcast where they discuss performance considerations when working with OCaml. What I was curious about was applying a GC language to a use case that must have extremely low latency. It seems like an important consideration, as a GC pause in the middle of high-frequency trading could be problematic.
[0] https://signalsandthreads.com/performance-engineering-on-har...
I actually asked Ron Minsky about exactly this question on Twitter[0]:
[0]: https://x.com/arr_ohh_bee/status/1672224986638032897Well on their way.. by having to write a ton of C for the interpreter. I think it’s really imprudent for them not to be using Rust yet for critical sections.
The problem is not a GC language per se, people keep putting all GC languages in the same basket.
The real issue is being a GC language, without support for explicit manipulation of stack and value types.
Want a GC language, with productivity of GC languages, with the knobs to do low level systems coding?
Cedar, Oberon language family, Modula-3, D, Nim, Eiffel, C#, F#, Swift, Go.
Does Go have much in the way of GC knobs? It didn't some years ago, but I haven't kept up on latest developments
The knobs aren't on the GC necessarily, rather language features.
With a Go compiler toolchain you have stack and global memory static allocation, use of compiler flags to track down when references escape, manually allocate via OS bindings, there is the unsafe package, and use slices with it, an assembler is part of the toolchain learn to use it, and regardless of CGO is not Go memes, it is another tool to reach for if Assembly isn't your thing.
Ohh right yes, now I get what you mean. My brain just immediately went for "GC knobs" when you mentioned "knobs", but in my defense I'm running a 40°C fever so I should probably not be commenting at all
All the best and get well.
.NET AOT compiles comically slowly. It makes C++ look like Ocaml. I have no idea how anyone uses it for anything serious.
GC compactions were indeed a problem for a number of systems. The trading systems in general had a policy of not allocating after startup. JS has a library, called "Zero" that provides a host of non-allocating ways of doing things.
Couldn’t find this after 6 seconds of googling, link?
The linked podcast episode mentions it.
There's no mention of a library called zero, or even JavaScript.
Im assuming the JS refers to Janes street
That makes sense, I guess I've got web tunnel vision.
I was bit by the same spider that gave you web tunnel vision. In any case, I find OCaml too esoteric for my taste. F# is softer and feels more..modern perhaps? But I don’t think GC can be avoided in dotnet.
You can avoid GC in hot loops in F# with value-types, explicit inlining, and mutability.
Mutability may not result in very idiomatic code however, although it can often be wrapped with a functional API (e.g. parser combinators).
> This is what I like to call a dialect of OCaml. We speak in sometimes and sometimes we gently say it’s zero alloc OCaml. And the most notable thing about it, it tries to avoid touching the garbage collector ...
> What I was curious about was applying a GC language to a use case that must have extremely low latency. It seems like an important consideration, as a GC pause in the middle of high-frequency trading could be problematic.
Regarding a run-time environment using garbage collection in general, not OCaml specifically, GC pauses can be minimized with parallel collection algorithms such as found in the JVM[0]. They do not provide hard guarantees however, so over-provisioning system RAM may also be needed in order to achieve required system performance.
Another more complex approach is to over-provision the servers such that each can drop out of the available pool for a short time, thus allowing "offline GC." This involves collaboration between request routers and other servers, so may not be worth the effort if a deployment can financially support over-provisioning servers such that there is always an idle CPU available for parallel GC on each.
0 - https://docs.oracle.com/en/java/javase/17/gctuning/parallel-...
Java is like C and C++, there isn't the one implementation.
So if you want hard guarantees, you reach out to real time JVM implementations like the commercial ones from PTC and Aicas.
You just let the garbage accumulate and collect it whenever markets are closed. In most cases, whenever you need ultra low latency in trading, you usually have very well defined time constraints (market open/close).
Maybe it's different for markets that are always open (crypto?) but most HFT happens during regular market hours.
Is that really a viable solution for a timeframe of 6+ hours?
Sure, if you know how much you allocate per minute (and don’t exceed your budget) you just buy enough RAM and it’s fine.
This will decrease performance because of reduced locality. Maybe increased jitter because of TLB misses.
Compared to what, running a garbage collector?
No, compared to not doing so many allocations that freeing them is time consuming or expensive. Having allocations slow a program down means that there are way too many, probably due to being too granular and being in a hot loop. On top of that it means everything is a pointer and that lack of locality will slow things down even further. The difference between allocating many millions of objects and chasing their pointers and doing a single allocation of a vector and running through that can easily be 100x faster.
Probably? Locality becomes fairly important at scale. That’s why there’s a strong preference for array-based data structures in high-performance code.
If I was them I’d be using OCaml to build up functional “kernels” which could be run in a way that requires zero allocation. Then you dispatch requests to these kernels and let the fast modern generational GC clean up the minor cost of dispatching: most of the work happens in the zero-allocation kernels.
(this comment was off topic, sorry)
Is this relevant to OCaml?
ha ha oops I got confused
I think it is, but to be clear I think (from my very limited experience, just a couple of years before leaving finance, and the people with more experience that I've talked with) that c++ is still a lot more common than any GC language (typically java, since OCaml is even rarer). So it is possible, and some firms seem to take that approach, but I'm not sure exactly how besides turning off GC or very specific GC tuning.
Here is a JVM project I saw a few years back, I'm not sure how successful the creators are but they seem to use it in actual production. It's super rare to get even a glimpse at HFT infra from the outside so it's still useful.
https://github.com/OpenHFT
Yes. It is a very common design pattern within banks for systems that only need to run during market hours.
I talk about doing this in an audio context and get met with raised eyebrows, I'd love some references on others doing it, if anyone can share!
You can just add more RAM until it is viable.
Are you aware of how many allocations the average program executes in the span of a couple of minutes? Where do you propose all of that memory lives in a way that doesn’t prevent the application from running?
Haven't looked at the link, but I think for a scenario like trading where there are market open and close times, you can just disable the GC, and restart the program after market close.
It is a common strategy.
*Jane Street
It's a great name for a competitor :)
The first feature that originated in this fork to be upstreamed is labeled tuples, which will be in OCaml 5.4:
https://github.com/ocaml/ocaml/pull/13498
https://discuss.ocaml.org/t/first-alpha-release-of-ocaml-5-4...
Yeah, pretty excited about this one even though it seems minor. A paper and talk by the author of this particular feature from ML2024, too:
- https://www.youtube.com/watch?v=WM7ZVne8eQE
- https://tyconmismatch.com/papers/ml2024_labeled_tuples.pdf
Anonymous labeled structs and enums are some of my top wished-for features in programming languages! For instance, in Rust you can define labelled and unlabelled (i.e. tuple) structs
But you can only e.g. return from functions an anonymous tuple, not an anonymous labelled structIn Dart, we merged tuples and records into a single construct. A record can have positional fields, named fields, or both. A record type can appear anywhere a type annotation is allowed. So in Dart these are both fine:
The curly braces in the record type annotation distinguish the named fields from the positional ones. I don't love the syntax, but it's consistent with function parameter lists where the curly braces delimit the named parameters.https://dart.dev/language/records
How do you distinguish a tuple with both positional and named fields from a tuple that has a record as a field
Like how do you write the type of (1, {sum:2}) ? Is it different from (1 , sum :2)?
The syntax is a little funny for mostly historical reasons. The curly braces are only part of the record type syntax. There's no ambiguity there because curly braces aren't used for anything else in type annotations (well, except for named parameters inside a function type's parameter list, but that's a different part of the grammar).
so my examples would be (1, (sum:2)) and (1, sum:2)?
Yes, exactly.
Hmm. Let me first check that I've understood what you care about
You want First and Fourth as the same type, but Second and Third are different - how about Fifth?I see that this is different from Rust's existing product types, in which First and Fourth are always different types.
Second though, can you give me some examples where I'd want this? I can't say I have ever wished I had this, but that might be a different experience.
they're not asking for a structural typing overhaul, just a way to make ad-hoc anonymous types with named fields and pass them around. a lot of times with tuple return types you're left wondering what that random `usize` is supposed to represent, so having names for it would be very convenient. i don't see why, under the hood, it couldn't just be implemented the exact same way as current tuple return types
> they're not asking for a structural typing overhaul, just a way to make ad-hoc anonymous types with named fields and pass them around.
And their point is that the two boil down to the same thing, especially in a non-trivial program. If switching field positions around changes their semantics, tuples may well the most sensible choice. As for "what that random usize is supposed to represent" that's something that can be addressed with in-code documentation, which Rust has great support for.
Also, if it's not just a "random usize" then you should use the new type paradigm. In a language like Rust that's not quite as smooth as it could possibly be, but it's transparent to the machine code. Rust's Option<OwnedFd> is the same machine code as C's int file descriptor, but the same ergonomics as a fancy Haskell type. We can't accidentally confuse "None, there isn't a file descriptor" for an actual file descriptor as we so easily could in C, nor can we mistakenly do arithmetic with file descriptors - which is nonsense but would work (hilarity ensues) in C.
If these aren't "random" usizes but FileSizes or ColumnNumbers or SocketTimeouts then say so and the confusion is eliminated.
It's interesting that languages which start with purely nominal structs tend to acquire some form of structurally typed records in the long run. E.g. C# has always had (nominally typed) structs, then .NET added (structurally typed) tuples, and then eventually the language added (still structurally typed) tuples with named items on top of that.
PHP has it all!
I think the main dividing line here is whether you want to lean into strict typing or whether you prefer a more loose typing structure. The extremes of both (where, for instance, the length of an array is part of its type definition or there are not contractual guarantees about data) are both awful. I think the level of type strictness you desire as a product is probably best dictated by team and project size (which you'll note changes over the lifetime of the product) with a lack of typing making it much easier to prototype early code while extremely strict typing can serve as a strong code contract in a large codebase where no one person can still comprehend the entirety of it.
It's a constant push and pull of conflicting motivations.
> Because sum:int * product:int is a different type from product:int * sum:int, the use of a labeled tuple in this example prevents us from accidentally returning the pair in the wrong order, or mixing up the order of the initial values.
Hmm, I think I like F#'s anonymous records better than this. For example, {| product = 6; sum = 5 |}. The order of the fields doesn't matter, since the value is not a tuple.
One reason why they're not the same is because the memory representation is different (sort of). This will break FFIs if you allow reordering the tuple arbitrarily.
Isn't that just the same as the ordinary OCaml { product = 6; sum = 5 } (with a very slightly different syntax)?
The difference between { … } and {| … |} is that the latter’s type is anonymous, so it doesn’t have to be declared ahead of time.
Oh I see, good point. I'm wondering how this is represented internally. Fields alphabetically? I've also desired extensible anonymous structs (with defaults) from time to time, but implementing that would involve some kind of global analysis I suppose.
Labeled tuples are effectively order-independent. Your implementation's order has to match your interface's order, but callers can destruct the labeled tuples in any order and the compiler will do the necessary reordering (just like it does for destructing records, or calling functions with labeled arguments). I don't think this is materially different from what you're describing in F#, except that labeled tuples don't allow labeling a single value (that is, there's no 1-tuple, which is also the case for normal tuples).
Immutable arrays were ported from this fork as well, and merged for 5.4; although with different syntax I think.
I wasn't aware that this fork supported SIMD! Between this, unboxed types and the local mode with explicit stack allocation, OxCaml almost entirely replaces my past interest in F#; this could actually become usable for gamedev and similar consumer scenarios if it also supported Windows.
Yeah, this would be great! Currently only 128-bit SSE/NEON is working but AVX is coming very soon. There's also nothing blocking Windows, but it will require some work. (I added the SIMD support in OxCaml)
FWIW, the "Get OxCaml" page actually says that SIMD on ARM isn't supported yet. If it actually works it would be worth removing that from the known issues list https://oxcaml.org/get-oxcaml/
Indeed, it says that because we don't have a library of NEON intrinsics (like ocaml_simd_sse) yet, but the extension itself works.
Ah, that clears it up a bit. Thanks! Looking forward to all of this. (For the interested readers, here's the SSE library: https://github.com/janestreet/ocaml_simd/tree/with-extension...)
Cool to hear there aren't any technical blockers to add Windows support! You just convinced me into giving OxCaml a try for a hobby project. 128-bit SSE is likely to be enough for my use case and target specs.
David Allsopp had an oxcaml branch compiling on Windows a few months ago, so it’s in the queue…
This is so cool.
If anyone's trying out the new opam switch, I found it helpful to use:
env OCAMLPARAM="alert=-unsafe_multidomain,_," opam install cohttp-lwt-unix
Because alerts are promoted to errors, they break existing package installs unnecessarily. The OCAMLPARAM environment variable just forces that alert to be disabled and allows the package installation to continue.
[dead]
OcaML's micro cousin:
http://t3x.org/mlite/index.html
Probably spoilt here but being used to the excellent vscode plugin (well vscodium in my case) for Golang but... any plans to integrate with vscode ecosystem? Makes setup so straightforward!
The OCaml vscode plugin seems to have already integrated a lot of new syntaxes (dune, menhir, reason), so if OxCaml gains traction it should only be a matter of time.
(can't really speak for that myself, though, I use emacs)
If you follow the installation instructions on oxcaml.org, you’ll get a patched Merlin with LSP support etc. It’s not perfect, but does mostly work out of the box with VSCode and the OCaml Platform extension.
Error squiggles and ocamlformat stopped working for me after the first time I restarted VS Code, compared to regular OCaml. They do work fine through the Dune CLI though.
Did you change the opam switch that vscode extension uses? It needs to be set to the oxcaml switch - you can do this via the "Ocaml: Select a Sandbox for this Workspace" command.
Yes I did, I'm used to working with opam, and when I first changed the switch it worked until I restarted VS Code. But since then I haven't managed to make it work again.
Hmm. Did you install ocaml-lsp-server on the OxCaml switch? I also tend to run dune in polling mode (-w), not sure if that matters…
Fwiw I had the same experience as debugnik with ocaml-lsp-server installed, irrespective of whether I built in polling mode.
So OxCaml is the extension of the extension of a dialect of ML.
Can’t wait for the next level
I had a similar thought to this, but then I thought, who is worse: programmers who keep bloating up existing languages with new features, or programmers who create yet another new language to add to the already crowded field? (I'm in that latter category.)
I guess programmers are just genetically incapable of leaving their tools the way they are.
This did actually halt my hobby programming language project, whose features overlap a lot and is advancing slowly anyway.
At the very least I'll give OxCaml a try to compare. Best case I drop mine and use this, worst case I learn what works and what doesn't.
Can I interest you in F#?
What are the chances that they are releasing this so that LLMs can index this information for free and they can use public models in their codebase rather than finetuning public models?
Given how poor LLMs are at regular OCaml, which has so much more training data that OxCaml, probably none. An MCP for docs would have been more productive for that purpose.
Not good at all. It's not a strong enough signal. For instance, LLMs are absolute dogshit at completing Gleam, even if given files with the exact pattern they need to mimic just lines away, or given explicit instructions on common mistakes it makes.
So this is "oxidized" because it tries to achieve the same features as Rust (e.g. "fearless concurrency" is mentioned, and avoiding GC)... Not because it actually uses Rust in any way right? Slightly confusing.
It's ironic of course because Rust (the language) is named after the fungus called Rust, rather than iron-oxide
Correct, Jane Street has been publishing a series of blog posts titled "Oxidizing OCaml" for a while.
Yes, they've used this terminology for a while, even the recent technical paper on this effort was titled "Oxidizing OCaml with Modal Memory Management", though the word "oxidize" itself is never actually referenced or defined in the paper. A bit strange, I agree, though it's kind of catchy I admit.
Rust will probably become usable with custom tracing GCs (which is helpful if you're dealing with general graph-like data but still want the highest performance as far as practical) way before this effort reaches genuine feature parity with Rust. Not seeing much of a point in this, unless they perhaps intend to focus on the lowest-hanging fruit and have big O(x)Caml codebases that they care about.
OxCaml takes a different approach to encoding locality to Rust. Rust (arguably) overburdens the type-system with this information whilst in OxCaml this is orthogonal to the return types. In that sense it's a bit like algebraic effects. Personally I'm quite bullish on OCaml these days.
> Not seeing much of a point in this
OCaml is a good language and these extensions are very welcome to existing OCaml programmers and programs, as well as many of the other extensions Jane Street has added. I don't understand what you mean here.
> > Not seeing much of a point in this
> ...I don't understand what you mean here.
Yeah it seems there was a mistake there, it looks like my comment got cut off while you were reading it. Try reloading the page maybe?
Your comment remains completely stupid regardless of how much of it is in the quote. OxCaml's goal is to be upstreamed. "I don't see the point in this unless people have programs using OCaml" and it's like, yeah, that's the point of adding features to a computer program. Any computer program. Because people already use the computer program and it will be useful to them.
Everything I see in OxCaml are things where I go: this would be nice to have in Ocaml.
[dead]
[dead]
[dead]
[dead]
Just use F# for sake
I actually see this as an escape opportunity for F#-ers. I love the language, but the runtime and C# ecosystem are not only holding it back from having cleaner semantics (until the C# team sees the value in them), they've been actively kicking it down the ladder with breaking changes and new incompatible APIs.
F# is mostly liberated from .net thanks to Fable. Although the compiler strictly is .net
Fable is the complete opposite direction to .NET and OxCaml, though. Nice for people doing web I guess (I'd rather do TypeScript than deal with interop), but the JS runtime and ecosystem are pretty much useless for my use cases.
Maybe a pure WASM target could actually liberate F#.
The sunk cost fallacy at Jane Street is strong.
Maybe it's sunk cost fallacy for them. But without them there wouldn't be a language that gets me 80/20 benefit/effort of Rust.
what is the sunk cost fallacy in the Jane Street case?
I said "maybe" as granting the root comment's premise - I don't believe that.
You can also argue it's "Stockholm syndrome". Anyway,it's funny how opinions differ: I still consider Rust to be a poor man's OCaml.
Why? They have one of the largest Ocaml codebases in the world. It has clearly work out VERY well for them, in terms of productivity and pure ROI in features and revenue.
Ocaml has so much good going on, even being a less known language.
I assume you are a rust fanboy, and i want to see just how long your smirk holds when you compile a 20M LOC project that takes 45 minutes.
I've never written a line of Rust in my life, but I unfortunately had the great displeasure to write OCaml.
OCaml is a terrible choice for (anyone) a company like this. They NEED to be able to hire the very best of the best, but choosing an exotic language that is less palatable than a plate of shit and more cryptic than alien hieroglyphs restricts your talent pool A LOT.
I'm not saying people cannot learn it, I'm saying people won't want to, for multiple very good reasons (it sucks, it's not at all transferable skill, etc.).
>They NEED to be able to hire the very best of the best,
This is literally why they've chosen Ocaml. Yaron Minsky has often stated that interest in a language like this is effectively a filter and magnet for extremely smart and curious people, he credits Ocaml with being an advantage in that regard.
They don't care about transferable skills either. People at Jane Street earn hundreds of thousands per year starting out, virtually nobody ever leaves, you're set for life after a decade there.
Aso Ocaml is a pretty standard ML. If you think it's unreadable alien hieroglyphs its fair to say you're not the demographic they're trying to attract, so the system is working.
Well said mate. Couldn't have said it any better.
Thats BS. I have learnt Ocaml and im far from "the best if the best". Its just syntax in the end, took me a few weeks to get productive enough to ship features.
Rust on the other hand, takes usually way longer to grok, mostly because of its borrow checker that is quite unique to rust.
This is not at all what I said. At least we can agree on the fact that you're far from being the best of the best with that reading comprehension...
Wait til you hear about PHP at Meta...
did they talked about it publicly ? i stopped following around the hiphop vm era
What are you talking about?
The implication here, I think, is that "Jane Street has foolishly invested heavily into Ocaml and, rather than sensibly change course and migrate away, they continue to invest heavily into it in the hopes that one day the investment will pay off."
Which is a ridiculous take: Jane Street has done extraordinarily well for themselves, possibly at least in part because of their investment in Ocaml, and any sort of migration would be a huge undertaking, and an absurd and unnecessary risk.
Ah yeah, that is absurd, given how successful they have been, and how much they attribute that success to their technical decisions.
People love to sulk in their parochial pits, I guess?
Thanks for clarifying :)
Maybe Jane Street succeeds because of the people who are good at finance in spite of the people who like OCaml.
I do think Jane Street fell into a sunk cost fallacy when they first stuck to OCaml. But after having invested further into an OCaml/OxCaml codebase, teams and tooling, switching tech stacks has lost most of its value.
Also, their efforts benefit me greatly as an OCaml (now maybe OxCaml) user, so I'm glad they took that path.
I dunno. Jane Street started using OCaml back in 2002. Consider the world of programming languages back then: no Rust, of course...but, like Java wouldn't even have generics for another two years! At the time - and for a long time after - OCaml's offering of power/performance was pretty unbeatable. It arguably still is, but I think there's at least an argument these days. I'm not sure exactly when that argument became viable, but it would've been long-after Jane Street had already built up a pretty huge codebase and a pretty crack team of OCaml engineers.