I think robustness is helped a lot by the fact that it’s the production compiler used at Jane Street
replyYeah; 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)
replyIt 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.
replyGCed 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.
replyLisp 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.
replyMentally 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.
replyIt'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.
reply