[0] https://signalsandthreads.com/performance-engineering-on-har...
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.
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.
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.
Mutability may not result in very idiomatic code however, although it can often be wrapped with a functional API (e.g. parser combinators).
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-...
So if you want hard guarantees, you reach out to real time JVM implementations like the commercial ones from PTC and Aicas.
Maybe it's different for markets that are always open (crypto?) but most HFT happens during regular market hours.
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.
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/ocaml/ocaml/pull/13498
https://discuss.ocaml.org/t/first-alpha-release-of-ocaml-5-4...
- https://www.youtube.com/watch?v=WM7ZVne8eQE
- https://tyconmismatch.com/papers/ml2024_labeled_tuples.pdf
struct Foo(i32, i32);
struct Bar{sum: i32, product: i32}
fn can() -> (i32, i32)
fn cant() -> {sum: i32, product: i32} (int, int) can() => (1, 2);
({int sum, int product}) alsoCan() => (sum: 1, product: 2);
(int, {int remainder}) evenThis() => (1, remainder: 2);
Like how do you write the type of (1, {sum:2}) ? Is it different from (1 , sum :2)?
struct First(this: i8, that: i64)
struct Second(this: i8, that: i8)
struct Third(that: i64, this: i8)
struct Fourth(this: i8, that: i64)
struct Fifth(some: i8, other: i64)
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.
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.
If these aren't "random" usizes but FileSizes or ColumnNumbers or SocketTimeouts then say so and the confusion is eliminated.
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.
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.
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.
(can't really speak for that myself, though, I use emacs)
Can’t wait for the next level
I guess programmers are just genetically incapable of leaving their tools the way they are.
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.
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.
> ...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?
Maybe a pure WASM target could actually liberate F#.
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.
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.).
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.
Rust on the other hand, takes usually way longer to grok, mostly because of its borrow checker that is quite unique to rust.
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.
People love to sulk in their parochial pits, I guess?
Thanks for clarifying :)
Also, their efforts benefit me greatly as an OCaml (now maybe OxCaml) user, so I'm glad they took that path.