Poly/ML is still compiling after 40 years
Standard ML has a production compiler that predates Java, runs on ARM64, and ships with a garbage collector tuned for symbolic computation.
I clicked on Poly/ML expecting archaeological documentation. What I found was a Standard ML compiler that got ARM64 support in 2021 and Windows ARM in 2024. Standard ML is the language academics point to when they want to show what Haskell could have been if it prioritised compilation speed over category theory. It has pattern matching, type inference, and a module system that makes Rust’s trait bounds look restrained. The catch: nobody teaches it outside of functional programming electives, and most people who learned it in the 1990s are now writing TypeScript. Poly/ML has been maintained since 1983. That is older than C++, older than Python, older than the web. The repository shows regular commits, bug fixes for the concurrent garbage collector, and patches for macOS Sequoia. Someone is keeping this thing working on hardware that did not exist when the project started. The interesting bit is the garbage collector. It is a generational collector optimised for symbolic computation, which means it handles large immutable data structures without copying them into oblivion. That matters for proof assistants like Isabelle, which uses Poly/ML as its runtime. When you are manipulating theorem trees with thousands of nodes, a naive GC will spend more time moving pointers than proving theorems. The README mentions native code compilation to x86, x86-64, and ARM architectures. No interpreter fallback, no JIT warmup. You compile once, you get machine code. The linking model is closer to OCaml than to JVM bytecode: separate compilation, static linking, and you can ship a binary without a runtime. I am not going to rewrite anything in Standard ML. But I respect a 40-year-old project that still compiles on my laptop without twelve dependency managers and a Docker container. That is rarer than it should be.