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

21–30 of 57 posts

Re: O(x)Caml in Space

#21

Post by greenarc »

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.

Re: O(x)Caml in Space

#22

Post by Decabytes »

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

Re: O(x)Caml in Space

#23

Post by satvikpendem »

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

Re: O(x)Caml in Space

#24

Post by zozbot234 »

netbioserror wrote: post #9
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…

Nim does much the same. It prefers the stack, wraps dynamic heap types in value-semantic unique pointers by default, and avoids implicit copies wherever it can. I could see compiled languages trending in the stack-managed direction long term.

It's more like a seamless generalization of the "stack-managed" pattern since async contexts also usually manage resources but don't reside on a stack.

Re: O(x)Caml in Space

#25

Post by zozbot234 »

Decabytes wrote: post #22

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

It's always difficult to have GC and non-GC objects interact seamlessly. You have to allow GC object finalizers to drop non-GC data, and non-GC objects to register GC objects they might reference as temporary roots (keep them alive) or somehow allow the GC tracing pass to discover what they might be referencing. And you still can't involve non-GC objects in any cycles, they have to be neatly self-contained leaf-like or tree-like sections of your reference graph.

Re: O(x)Caml in Space

#26

Post by zozbot234 »

noelwelsh wrote: post #14

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. [1]: https://noelwelsh.com/posts/a-quick-introduction-to-oxcaml/

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.

Re: O(x)Caml in Space

#27

Post by Maksadbek »

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?

Re: O(x)Caml in Space

#28

Post by legobmw99 »

zozbot234 wrote: post #26
noelwelsh wrote: post #14

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. [1]: https://noelwelsh.com/posts/a-quick-introduction-to-oxcaml/

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)

Re: O(x)Caml in Space

#29

Post by javcasas »

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.

> 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?

Re: O(x)Caml in Space

#30

Post by eriangazag »

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…

(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!

Post reply on HN