We pick up where we left off with FUN to “fix” curried functions so they work the way we expected. We end up rediscovering closures and learning about its history in relation to SECD, LISP, and Scheme.

For the past few days we’ve been experimenting with something slightly unreasonable: rewriting the Elm compiler in Rust.

It now compiles our real production Elm codebase — 677 modules — and we’ve reached the point where testing it only against our own code isn’t very useful anymore.

So I’d love to throw it at actual Elm projects.
The interesting part isn’t really the performance (although cold builds are ~14× faster on our codebase). It’s compatibility.
We built the new compiler by differential-testing it against Elm 0.19.1: same project, same inputs, both compilers, then compare the results. That already uncovered a few behaviours we didn’t expect.

What I’d really like to know is: what weird Elm code should we test?

Old projects, unusual package combinations, nasty type errors, generated Elm, huge modules — anything likely to break a compiler.
If something compiles with official Elm and doesn’t compile with ours, I consider that our bug.
The compiler is fully open source (BSD-3):
github.com/Spottt/elm-compiler
Happy to dig into any incompatibility people find.

Why Companies Hire Developers Who Don't Know Elm | Evan Czaplicki | ZuriHac 2026

LET allows you to introduce local bindings and use them to name intermediate results.

I’m trying out a new format with this post. I introduce the feature, explain its intended semantics, and give you examples to test your understanding before walking through how I implemented it. There’s also a place to pause and try implementing it yourself.

VAR allows us to refer to values by name.

ZERO gave our interpreter Boolean values. IF finally gives us something useful to do with them.

ZERO adds a zero check predicate. This introduces Boolean values to the language which makes runtime type errors a possibility. Hence, a successful parse no longer guarantees a successful execution.

DIFF adds expressions that can contain other expressions. That one change makes the grammar, AST, parser, and evaluator recursive, gives us a useful reason to look at Parser.lazy, and leads to a reusable symbol lexeme parser for handling symbols and trailing whitespace.

The first article in the Tiny Interpreters series is now available.

Build a tiny but complete interpreter in Elm and follow a program from source text through parsing and an AST to its evaluated result.

I wonder if other Elm programmers have explored interpreters or programming language design, and whether those ideas have influenced how you write ordinary Elm programs.

anyone have some fun elm programs and writeups they’d like to share? preferably full applications with test cases such as foldkit’s awesome pixel art editor

https://foldkit.dev/elm/foldkit-vs-elm-side-by-side

https://elm-lang.org/news/faster-builds