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

41–50 of 57 posts

Re: O(x)Caml in Space

#41

Post by rho_soul_kg_m3 »

avsm wrote: post #19
rho_soul_kg_m3 wrote: post #17

Earlier quoted context omitted.

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

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

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}

Re: O(x)Caml in Space

#42

Post by pjmlp »

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…

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.

Re: O(x)Caml in Space

#43

Post by giraffe_lady »

kcsrk wrote: post #13

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

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.

Re: O(x)Caml in Space

#44

Post by pjmlp »

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…

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.

Re: O(x)Caml in Space

#46

Post by pjmlp »

cmrdporcupine wrote: post #39
javcasas wrote: post #29

Earlier quoted context omitted.

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

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.

Re: O(x)Caml in Space

#47

Post by pjmlp »

runevault wrote: post #40
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 collec…

This was pretty common in the 1980's-90's, for some strange reason, maybe due to Java and scripting languages, there is this mentality that having a GC means no stack allocations.

Lisp Machines dialects (Genera, TI, Xerox) had primitives for stack allocation.

Them we had Cedar, CLU, Oberon and all its descendants, Modula-2+, Modula-3, Eiffel, Sather, and probably others during the last century.

Ironically the final design for Valhala in Java seems to be quite close to Eiffel already had in 1986.

Re: O(x)Caml in Space

#48

Post by pjmlp »

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…

Depends if the language supports value types and stack allocation or not.

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.

Re: O(x)Caml in Space

#49

Post by pjmlp »

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.

Only for GC haters.

For the rest of us, languages with automatic resource management are perfectly usable in systems programming.

Re: O(x)Caml in Space

#50

Post by pjmlp »

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/

Xerox already proved that with Cedar on the Dorado, and Interlisp-D, as did many others since then.

http://toastytech.com/guis/cedar.html

https://interlisp.org/

Unfortunately those attempts end up failing due to human reasons, not technical ones.

Post reply on HN