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 think robustness is helped a lot by the fact that it’s the production compiler used at Jane Street
Yeah; all the really dangerous extensions are gated behind flags. But there's still a very significant number of optimisations available by default that just work well. I've taken to compiling my normal OCaml code with OxCaml these days to get a free speed boost (but buyer beware: the dependency management can be tricky; I have a giant monorepo to help out https://github.com/avsm/oxmono)
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<T>, Memory<T>, 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 collect).
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.
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.
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.