Note that the focus here is to make it safe to have mutable data around, not to have manual memory management.

Next up I hope:

  - https://www.youtube.com/watch?v=0jI-AlWEwYI
    https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md

I think for people who need absolute performance, manual memory management seems inevitable. No amount of GC tuning or hacks (such as the wonderful compact regions) would be satisfactory.

This enables more kinds of programs to be written in Haskell, whereas your day-to-day typical server programs can just use GC as they currently do.

If one needs absolute performance, then their only option is bare metal, as the OS can also induce every kind of delay, including RTOS, so manual == performance goes a long way until it is actually true.

A unikernel library could put your key process front and center, only providing a unified way to access the hardware.

Things become more interesting when you start to need concurrency. You can of course do it manually, too, controlling every fiber switch (I've seen this done in an engine controller, where all the computatios should complete within one rotation of the shaft.)

Funny how you mentioned unikernel. There's a Haskell unikernel whose development began more than a decade ago: https://github.com/GaloisInc/HaLVM