Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

O(x)Caml in Space

gazagnaire.org

Post reply on HN
Print view View original

31–40 of 57 posts

Re: O(x)Caml in Space

#31

Post by skyblock500 »

greenarc wrote: post #21
rho_soul_kg_m3 wrote: post #12

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 r…

Oh, hey Berké, The GHGSat constellation's payload software is still mostly OCaml, although a limited amount of newer from scratch components are indeed in Rust. It's been working well and on 16 satellites now - but as you said the main challenge has been training developers to Ocaml and I doubt they would write new code in it now.

If it ain't broke why fix it?

Re: O(x)Caml in Space

#32

Post by eriangazag »

Maksadbek wrote: post #27

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?

(author of the post here)

Hey Maksadbek! Great question. It's a trade-off between speed of writing and trust in what you wrote, and OCaml (especially OxCaml) sits at a really good point on that curve.

Ada/SPARK has the strongest verification story and decades of space heritage, but the development cost is higher. Rust would work too, but I actively want a GC by default with the option to turn it off on the hot path. That is exactly what OxCaml's mode system gives you: zero minor GCs on the dispatch loop in the post, while the rest stays GC-managed. Haskell is great for type-driven design but its runtime cost-model is harder for low-jitter work.

Plus, the OCaml ecosystem gave me solid foundations on both fronts. For the protocol stack: MirageOS-style clean separation between wire serialisation, pure state-machine management and I/O, with ML modules and GADTs that map naturally onto protocol state machines. For the crypto: mirage-crypto for OCaml-facing primitives (fiat-crypto under the elliptic curves), and libcrux for ML-DSA-65 post-quantum signing. The CCSDS and BPv7/BPSec layers themselves I had to write from scratch (my earlier posts walk through how), and 20 years of OCaml muscle memory definitely helped!

Re: O(x)Caml in Space

#33

Post by noelwelsh »

legobmw99 wrote: post #28
zozbot234 wrote: post #26

Earlier quoted context omitted.

OxCaml is more of a competitor to Go, JS/Typescript or the Java/.NET ecosystems than these two other languages. It's also a temporary effort that's ultimately intended to feed into upstream Ocaml.

I think that’s not true; vanilla OCaml is already a competitor to Go, etc. OxCaml is explicitly an effort to compete more with Rust (the “Ox” in the name is to evoke “oxidizing” = rusting)

Agreed with this. OxCaml still requires a runtime, so it's not suitable for some applications, like embedded systems, where e.g. Rust can be used. But it certainly can be used for many of the same applications. E.g. Bun, which has been on the home page recently, could easily be written in OxCaml.

Re: O(x)Caml in Space

#34

Post by eriangazag »

dsab wrote: post #6

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+e…

(author of the post here)

Hey dsab! I agree, but CCSDS is what we have today. We need to support it properly first if we ever want to extend or transition away. It also doesn't help that there's no good open-source implementation of the whole stack, especially the SDLS part, which makes the transition even harder.

On the type-safety side, I found typed combinators really useful for describing parsing and serialising (see my earlier post on ocaml-wire[1]), and keeping the protocol logic pure (separate from I/O) makes the whole thing much easier to test and reason about. OCaml's fuzzing support pairs really well with types too. This is basically the nqsb-TLS approach [2], which has held up in ocaml-tls for a decade.

[1] https://gazagnaire.org/blog/2026-03-31-ocaml-wire.html [2] https://www.usenix.org/conference/usenixsecurity15/technical...

Re: O(x)Caml in Space

#35

Post by ffaser5gxlsll »

rho_soul_kg_m3 wrote: post #12

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 r…

> 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").

Re: O(x)Caml in Space

#36

Post by skyblock500 »

ElectronCharge wrote: post #20
DeathArrow wrote: post #18

>KC ended his talk speculating that OCaml 5.0 would go to the moon, due to its language features that would deliver C/Rust-like performance That is quite an affirmation! I would likle to see OCaml being there.

I'll have to take a look at OxCaml. I'm leery of "C-like" performance claims after Java has thoroughly failed to live up to a similar claim after thirty plus years of development... What it's actually achieved is about 50% C performance, IF you're willing to give it a huge heap, at least 2x the actually required memory. Rust is clearly well positioned for deeply embedded work, and has actual C/C++ level performance.…

With the recent direction Mojo has taken, that dark horse sounds more like a pipedream to me

Re: O(x)Caml in Space

#37

Post by Maksadbek »

eriangazag wrote: post #32
Maksadbek wrote: post #27

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?

(author of the post here) Hey Maksadbek! Great question. It's a trade-off between speed of writing and trust in what you wrote, and OCaml (especially OxCaml) sits at a really good point on that curve. Ada/SPARK has the strongest verification story and decades of space heritage, but the development cost is higher. Rust would work too, but I actively want a GC by default with the option to turn it off on the hot path.…

Hey Thomas, thank you for detailed explanation! This sounds very interesting. I really wanted to learn something less complex than Rust/Haskell and fast enough for high performance computing and also reliable language. I should learn some OCaml :)

Re: O(x)Caml in Space

#38

Post by michaelcampbell »

legobmw99 wrote: post #28
zozbot234 wrote: post #26

Earlier quoted context omitted.

OxCaml is more of a competitor to Go, JS/Typescript or the Java/.NET ecosystems than these two other languages. It's also a temporary effort that's ultimately intended to feed into upstream Ocaml.

I think that’s not true; vanilla OCaml is already a competitor to Go, etc. OxCaml is explicitly an effort to compete more with Rust (the “Ox” in the name is to evoke “oxidizing” = rusting)

> the “Ox” in the name is to evoke “oxidizing”

Hah, I was reading it as `0x`, a common prefix indicating hexadecimal, though I can't say my brain made any leap as to why "0xCAML" would be any more hex than standard.

Re: O(x)Caml in Space

#39

Post by cmrdporcupine »

javcasas wrote: post #29
greenarc wrote: post #21

Earlier quoted context omitted.

Oh, hey Berké, The GHGSat constellation's payload software is still mostly OCaml, although a limited amount of newer from scratch components are indeed in Rust. It's been working well and on 16 satellites now - but as you said the main challenge has been training developers to Ocaml and I doubt they would write new code in it now.

> the main challenge has been training developers to Ocaml and I doubt they would write new code in it now Why do I never hear about these kinds of opportunities? I have done some Ocaml, quite a bit of embedded systems, and these days I have to waste the years doing web development. Where do I have to call to be considered for doing OCaml embedded systems?

Right, I always find these kinds of statements about "we can't find talent in " a bit confusing because I personally know all kinds of people always desperate to find work in neat-lang be it Haskell, OCaml, whatever... But the opportunities never seem to be there.

And it was only 3-4 years ago (maybe less) that Rust was considered by hiring managers to be in that category, too. Ask me how I know.

I'm going to assume it really means that they can't find people who satisfy some other constraint (location, pay band, "required" degree, experience on some other system or in some industry, etc) and OCaml or whatever.

In any case, LLMs blunt this. Hell, please stop me from opening a tab and starting a new OCaml project right now.

Re: O(x)Caml in Space

#40

Post by runevault »

avsm wrote: post #3

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 'htt…

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, Memory, 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).

Post reply on HN