Hacker News Reader

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.

Because in general, when they get the candidates that could fit the position, they get grilled in meaningless letcode interviews, or classical stuff like how many golf balls fit into a plane.

The pool is already small, and gets reduced even further.

Probably because the requirement is not knowing ocaml but knowing how to do X, preferably in ocaml.

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.

Given the kind of computer I had in 1996, you can even run in less, because I did so when the official name was still Objective Caml, and Caml Light was heavily used in education.

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

Thanks. Regarding open-sourcing, well no, it's not up to me, and it would be kind of proprietary.

The size variants for floats and integers is definitely appreciated.

For the "read-only BigArrays": At the time I didn't know any Rust, but today that would simply be passing a mutable or immutable reference. Similar to the Fortran in/out designators in some way. I think that's pretty important when you have some complicated numerical code, sometimes with in-place modification.

Since there is a "zero_alloc checker", maybe a similar kind of annotation exists or could be added? Something like

  let foo (x : [@readonly]) = ... 
    x.{0} <- 1.23

  ^ Attempt to write to read-only array

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.