Comment by rho_soul_kg_m3
17 hours ago
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.
EDIT: Found my slides https://lambda-diode.com/static/data/GHGSat_OCaml.pdf
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 <'weird' language X>" 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.
2 replies →
If it ain't broke why fix it?
(author of the post here)
Hey Berké! I remember your talk very well (I was in the room), super interesting and it really got me thinking about this area!
Since then, the more I look into it, the more I see a fit with our MirageOS unikernel work. On the ground, you can paper over security and specialisation by throwing more machines (or money) at the problem. In orbit you cannot, so both the compile-time and the runtime guarantees have to be right!
Hello :) Glad to hear the talk was useful.
You say you're using Linux as the underlying OS, but you must have looked at bare-metal embedded usage as well.
How feasible would you say it is, today, to use OCaml with MirageOS (or something similar) on a bare-metal target, say a small softcore RISCV32 with 256kB of RAM?
> 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").
In general, if it works, leave it alone; but I can think of two reasons to stop using OCaml:
1) You have been ordered to directly interface with some external library that has a complicated C ABI, and you can't isolate it in a separate process and do IPC, and the FFI would be too clunky or slow.
2) You really need to manipulate lots of bits or bytes or floats very fast, or there are lots of them, and speed or memory footprint is becoming an issue. You need to multicore and/or SIMD, you need efficient abstractions, and you do that kind of thing all over the place, not just in a few functions that you separately implement in C or whatever.
As a bonus here's a good reason for NOT leaving OCaml: You can quickly bootstrap the compiler and run it on small embedded machines. I remember using OCaml on a Cyrix 686 with 64 megs I think, it was perfectly fine. Today, the lights dim a bit when I start cargo build.
Do you have a link to your talk? I'm also curious if you did any GHG measurements, or it was part of the control stack. We wrote the XenServer stack in OCaml back in 2004, and that made it into orbit in 2017 (I think it did, anyway: https://www.theregister.com/offbeat/2017/05/12/space-upstart...)
Yes see above.
OCaml was very much part of the GHG measurements. On the satellite it was controlling the cameras, acquiring the images, losslessly compressing them, encrypting them and transferring them to the platform controller using a clunky but mandated CSP-based file tranfer protocol. On the ground, OCaml was running almost the entire data processing chain, including spectroscopy, image corrections, retrievals and post-retrieval ad hoc bias corrections, as well as simulations.
I simply used an mmap()'d Bigarrays to do parallel processing (back then OCaml wasn't multi-core.)
At a later stage I replaced a few bits of code (e.g. some sparse matrix routines) with Fortran. The only processing-related part that wasn't OCaml (besides the shells scripts to glue the things together) was the image alignment algorithm which was written by someone else in C++. I even had a job scheduling system written in OCaml.
Nice work! Did you ever open any open source any of it? Looking at your OCaml wishlist from back in 2017, some stuff has improved and some is on its way:
- Support for read-only BigArrays (or sections) : we're starting to switch to just using bytes/string in OCaml 5+ now, since the larger allocations go into malloc'ed pools and do not relocate, so they can be used as part of an FFI (without the Bigarray C value overhead)
- More support for floating-point numbers (exceptions, representation exploration): OxCaml has some of this now! https://oxcaml.org/documentation/miscellaneous-extensions/sm...
- Syntax for extended BigArray indexing: now supported in OCaml https://ocaml.org/manual/5.4/indexops.html#ss:multiindexing
- LaCaml remains too low-level (non-functional) and unreadable: still remains the case, but OxCaml's got initial support for SIMD https://oxcaml.org/documentation/simd/intro
- BigArray and floating-point I/O remains difficult (we would like: I/O to channels, efficient representation retrieval): much easier now with OCaml effects to build custom fast serialisers (see https://github.com/ocaml-multicore/eio)
- Native top-level: ocamlnat is (I think) shipped in OxCaml, but you can also run a wasm toplevel
1 reply →
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.
Thanks for the presentation.