The big win here is having a GC by default, with the ability to reduce heap allocations (via stack) just by adding in more typing annotations.
Switching to OxCaml with exclave_ stack_ annotations drops
p99.9 latency from 29 ns to 9 ns per packet on the dispatch
hot path, and removes GC pressure entirely (394 minor GCs to
zero over 25 million packets). Throughput is comparable [...]
I got a similar result with my 'httpz' stack a few months ago (https://anil.recoil.org/notes/oxcaml-httpz) which my website's been running on without drama. And, I gotta say, OxCaml's a surprisingly robust compiler for being packed full of bleeding edge extensions: not a single crash on my infra is attributable to a compiler bug (plenty of bad OCaml code, but not due to a compilation bug)
It is interesting seeing more and more GCed ecosystems become aggressive about allowing code to stack allocate more. Watching dotnet go through it since I think Core 2.1, or whenever they introduced Span<T>, Memory<T>, etc to get significant performance gains has been nice to track.
GCed languages do not have to be slow if you keep the garbage to only where it is necessary (or where you can allocate once and never collect).
Yes, just like PTC and Aicas have been delivering real time GC with their embedded Java toolchains, microEJ, Astrobe with Oberon, and Meadow with their micro kernel + .NET.
Mentally only gets changed with people pushing against "this is how it has always been".
Also great to see the OCaml improvements, as my first ML was Caml Light.
CCSDS guides you to reinvent everything from scratch, I doubt memory safety is the biggest attack surface when you implement this stack. I dont know how big players implement networking for their satellites, but personally I would choose to fit something existing and battle-tested like TLS instead of reinventing data encryption, just look at those documents: https://www.google.com/search?client=firefox-b-lm&q=ccsds+en...
> battle-tested like TLS instead of reinventing data encryption
Working in the industry, CCSDS SDLS is quite battle tested, albeit in a different way than TLS. It's not reinventing everything from scratch; in most cases, companies have common libraries and services that they've been using since the 90's that implement the standards. I found it interesting that a lot of the CCSDS standards sound a lot like internet standards because many were developed alongside the internet standards, just targeting constrained space systems rather than ground systems.
TLS is difficult because it doesn't work well when you get to large latencies (e.g. 700ms in LEO to ~1.5s in GEO). CCSDS standards target general space systems, so they have to account for that latency.
Well, I might have been the first to put OCaml in space, specifically on low-Earth orbit aboard GHGSat-D in 2016. I designed the payload software as a collection of SystemD services talking over DBus, and it included a CCSDS-to-DBus bridge to talk to the platform (the thing that hosts the payload, controls and steers the satellite). The payload also did perform symmetric-key encryption of the resulting data, as per regulations.
I gave a talk about the payload software at the Paris OCaml users group.
The reason for selecting that archicture was that I didn't expect to write the whole payload software by myself, and I assumed that when some other developers join in they would, obviously, not want to use a weird language like OCaml, and so they could write their portion in C/C++/whatever and the system could still work. Of course that didn't happen.
I'd be surprised if the company still uses OCaml, as the standad tendency is to revert to "industry-standard" languages to get industry-standard problems. The whole processing and simulation toolchain was also written in OCaml.
Today there is little reason not to use Rust and it can cover both the processing side and the payload software. But people still insist on using C/C++. I'm OK with that as long as I can invoice them.
> Today there is little reason not to use Rust and it can cover both the processing side and the payload software. But people still insist on using C/C++. I'm OK with that as long as I can invoice them.
Any reason _not_ to continue using ocaml besides being less popular?
If popularity/mindshare wasn't an issue, I find the development cycle with ocaml to be nicer in several ways compared to rust on a platform where stuff like python is already allowed (I wouldn't call a full-blown linux system, even with limited memory, "embedded").
Besides certification issues, it is a matter of culture.
That is why I say I see Rust main domains, environments where any form of automated resource management is not possible due to technical reasons, or (your point) it is a waste of time trying to convince people out of their beliefs.
What’s surprised me in the last few months is that agents are great at producing OCaml 5+ and OxCaml code, not much of which is out there in the training data. OxCaml’s strong types and modes seem to serve as great testable oracles to guide the agents.
I taught a course on concurrent programming based on OCaml 5 and OxCaml where almost all of the code in the teaching materials were vibe coded. I reviewed all of the code (because I was teaching it to a class of 50+ students) and frankly the agent writes better O(x)Caml (mostly) than me.
There is some bizarre facility with hindley-milner based languages embedded in LLMs, they're basically automatically good at even very new ones like gleam and nanolang. I have a never-released-anywhere hobby ML that compiles to lua and coding models can write it fine. Better than it writes python or php for sure and those have huge corpuses in the training data.
I don't even have good conjecture about why this is the case but right now all my assisted coding is in MLs for this reason.
HN is currently obsessed with Rust vs Zig. OxCaml should be considered as an alternative to both. The argument for Rust is safety, while for Zig it's ergonomics, but OxCaml shows you can have safety and ergonomics together. In my little tinkering with it [1] I found it really easy to use.
I know that many garbage collected languages have ways of reducing gc pressure by minimizing classes, and pushing more things on the stack. I’ve even heard how languages like Java will allocate a massive amount of memory in the beginning, and then turn. Off the garbage collector for the whole day in high frequency trading scenarios.
Having never been in this situation, I wonder how difficult it is to bend a garbage collected language to behave like a non garbage collected one
I've long thought that Rust needs a similar algebraic effects system to OCaml 5, has anyone used both and compared how well they work for various use cases? Rust is of course more mature than OxCaml but if it's good enough for Jane Street...
I'm not deeply familiar with reliability-focused languages, but as far as I know, Ada, Rust, and Haskell are the most prominent ones. What made OCaml a better choice here over those alternatives?
22 comments
[ 2.5 ms ] story [ 39.3 ms ] threadGCed languages do not have to be slow if you keep the garbage to only where it is necessary (or where you can allocate once and never collect).
Mentally only gets changed with people pushing against "this is how it has always been".
Also great to see the OCaml improvements, as my first ML was Caml Light.
Working in the industry, CCSDS SDLS is quite battle tested, albeit in a different way than TLS. It's not reinventing everything from scratch; in most cases, companies have common libraries and services that they've been using since the 90's that implement the standards. I found it interesting that a lot of the CCSDS standards sound a lot like internet standards because many were developed alongside the internet standards, just targeting constrained space systems rather than ground systems.
TLS is difficult because it doesn't work well when you get to large latencies (e.g. 700ms in LEO to ~1.5s in GEO). CCSDS standards target general space systems, so they have to account for that latency.
I gave a talk about the payload software at the Paris OCaml users group.
The reason for selecting that archicture was that I didn't expect to write the whole payload software by myself, and I assumed that when some other developers join in they would, obviously, not want to use a weird language like OCaml, and so they could write their portion in C/C++/whatever and the system could still work. Of course that didn't happen.
I'd be surprised if the company still uses OCaml, as the standad tendency is to revert to "industry-standard" languages to get industry-standard problems. The whole processing and simulation toolchain was also written in OCaml.
Today there is little reason not to use Rust and it can cover both the processing side and the payload software. But people still insist on using C/C++. I'm OK with that as long as I can invoice them.
EDIT: Found my slides https://lambda-diode.com/static/data/GHGSat_OCaml.pdf
Any reason _not_ to continue using ocaml besides being less popular?
If popularity/mindshare wasn't an issue, I find the development cycle with ocaml to be nicer in several ways compared to rust on a platform where stuff like python is already allowed (I wouldn't call a full-blown linux system, even with limited memory, "embedded").
That is why I say I see Rust main domains, environments where any form of automated resource management is not possible due to technical reasons, or (your point) it is a waste of time trying to convince people out of their beliefs.
Thanks for the presentation.
I taught a course on concurrent programming based on OCaml 5 and OxCaml where almost all of the code in the teaching materials were vibe coded. I reviewed all of the code (because I was teaching it to a class of 50+ students) and frankly the agent writes better O(x)Caml (mostly) than me.
I don't even have good conjecture about why this is the case but right now all my assisted coding is in MLs for this reason.
[1]: https://noelwelsh.com/posts/a-quick-introduction-to-oxcaml/
http://toastytech.com/guis/cedar.html
https://interlisp.org/
Unfortunately those attempts end up failing due to human reasons, not technical ones.
That is quite an affirmation! I would likle to see OCaml being there.
Having never been in this situation, I wonder how difficult it is to bend a garbage collected language to behave like a non garbage collected one
Many GC languages do so.
The hard part is that the difference is part of the type system, and you might need to refactor some code moving between value and reference types.
https://spacebook.com/explorer?scene=8451c006-9e1a-4943-8202...