Martin from Spottt has written an article about their new Elm compiler written in Rust.

The article details the reason for their decision to rewrite the Elm compiler in Rust, basically build times:

Elm 0.19.2 made builds much faster for many projects, but not for ours: our application is probably an outlier for the Haskell compiler.

I wonder if they have the same issue that we had at Pakk, which I realise now I never blogged about before. Our issue was the use of large record types. The Elm compiler expands these record types and crucially stores that expanded type in the incremental build files .elmi and .elmo. That meant that these files became very large, and it was the parser of these files that was taking a long time in the compilation. That was why even for an incremental build the compiler would still sometimes take a long time. We had a simple script to find large .elmi files:

#!/bin/sh

du -hs elm-stuff/0.19.1/* | sort -h | tail -n 50
du -hs elm-stuff/0.19.1/

Once you have these large files you can guess which large record types to make opaque. It’s not trivial, because it’s not necessarily a large record type by itself, it may contain a reference to a large record type. We generally found that making these types opaque reduced the compile-time, though it was generally not an improvement for the code.

Anyway the post continues with a discussion of how their new compiler, written in Rust, was generated by some relatively trivial prompting of an LLM coding agent. Then, more importantly discusses how they kept that coding-agent honest, that is, how they checked its work. The main idea was to use the current official Elm compiler as an oracle, and just throw as much Elm code at both as possible, and compare the outputs.

They found several bugs in the official Elm compiler, some of which have been fixed in Elm 0.19.3 which has now been released.

So great stuff. I like that LLM coding agents make such experiments doable.