Eco - Compile Elm to native code

Show and Tell
1

I am delighted to be able to share my new Elm compiler project with you today.

eco - Elm Compiler Optimized - is a new optimizing compiler infrastructure for Elm. Here is eco - introduction

site-image
site-image810×523 77.3 KB

eco is fully open sourced today - GitHub - eco-lang/eco-compiler: eco compiler for elm · GitHub

Some things about eco that may interest you:

  • Self-compiling “boot strapped” compiler.
  • Front-end in Elm, back-end in C++. No Javascript and no Haskell.
  • Generates x86 native code via MLIR and LLVM (arm64 for Mac soon)
  • Generational Garbage Collector
  • Aims to be 100% Elm compatible (core, json, bytes, http, regex, url, parser, time, already implemented)
  • Can run existing Platform.Worker + NodeJS programs with Elm.init and ports in Javascript linking to a native binary for the Elm program.
  • Int compiles to native 64-bit integers
  • There are > 150,000 elm-test tests against the front-end compiler pipeline.

What are the long-term goals here ?

  • A multi-threaded Elm runtime with parallel Tasks and TEA Actors
  • Support for servers with high core counts and large RAM - eco supports 8TB address space.
  • Throughput and latency to match C++/Rust/zig
  • Ref counting and optimistic mutation optimizations to replace GC.
  • Keep the gradual migration path from existing 0.19 Elm programs on NodeJS
  • Potential pathway to compiling web apps to WASM.

Ok, those are some grand claims and there is a long way still to go to achieve them, but I wanted to share my vision for what I believe will be possible.

The version being made public today is 0.1.0 alpha.

Please note that the alpha label is a suggestion that you should interpret this work as experimental today. There will be bugs, possibly even severe ones. Please find some bugs and tell me about them in the GitHub issues. This is the whole point of making an alpha release and starting the journey of the code from my computer to meet the real world.

Some limitations of eco 0.1.0 alpha:

  • Single threaded, including the whole compiler pipeline, the compiler is not fast.
  • Runtime performance is moderate - roughly the same as running under NodeJS.
  • Minimal IO API (to support the compiler).
  • GC pause times are significant, it is single threaded, your program thread does the collection work.
  • “hello world” binary is 8MB in size - mostly debug symbols. Needs debug stripping and not linking unused kernel code - should be around 100KB after that.
  • 0.1.0-alpha release only supports Linux x86. Windows and Mac builds will follow very soon.

It is risky to make an early release such as this if people are expecting higher performance because it compiles to native. Please be understanding of the early version number and experimental nature of this project at this time.

I am confident that performance can be greatly improved, all the techniques are known, it is just a question of putting in the work to implement them. Right now there are so many levers to pull on to make it faster, the harder choice is choosing the correct levers to pull first.

eco has its compiler front end implemented in Elm. This part started its life as the Guida elm-in-elm compiler. eco adds a new pipeline to that codebase for an optimizing compiler pass that generates native machine code. The back-end code generation part of eco is implemented in C++ and built on top of LLVM and MLIR. There is a well defined bytecode at the boundary between front-end and back-end, called the “eco dialect”.

The compiler is already capable of self compiling. This is a 160K LOC codebase, some of which makes heavy use of continuation passing style. There are over 150,000 tests applied to the code, and over 1000 end-to-end Elm test programs that try to cover many corner cases of the language itself. So you should find that the compiler is well tested and capable of handling large and complex programs.

I began working on eco in November last year. Since this is the second elm-to-native compiler you are hearing about in just a few short weeks! It is worth mentioning that eco is an entirely separate and independant project. eco builds a new compiler pipeline that branches off at the type checking phase to enable more high level optimisations that operate at the language level and make use of type information - such as monomorphization.

Full disclosure - most of the code is implemented by AI, Claude Code specifically. It is not “vibe coded”, there is a strong software engineering and design element to drive that code generation. Without AI this project could have taken 2 or 3 years to implement at least. The structure of the code is good and not a mess. My current feeling is that I should use less AI during a tidy up phase of the code, in order to ensure that the kinds of mistakes that AI can make get reviewed out. But I want to be transparent about this in case you are against AI - you might not like what you find here!

3 Likes
2

Dude. Do your thing, but don’t plagiarize my design and my roadmap!

Take that page down please. Should have been enough when I said that back in February.

elm-run.dev/roadmap
elm-run.dev/roadmap1744×2002 254 KB

plagiarized-roadmap
plagiarized-roadmap1156×2078 357 KB

If such “strong engineering” went into this, how come the “dialect” magically retroactively became “bytecode” and it all become a “runtime” only on June 3? Wonder what happened on June 2? "🤔"

From: Rupert Smith
Date: Wed, 3 Jun 2026 14:26:26 +0100
Subject: [PATCH] Correcting links to github repo, removing discord server
 link, updated roadmap to correct state.

...
diff --git a/content/roadmap.md b/content/roadmap.md
index 0d1e62c..9f684da 100644

-- [x] MLIR 'eco' dialect established, compilation via LLVM to x86 binaries.
+- [x] eco bytecode dialect established, compilation via LLVM to x86 binaries.
...
-              "https://github.com/eco-lang/eco"
+              "https://github.com/eco-lang/eco-runtime"

Blows my mind you have no shame doing it like this publicly. Really makes milestone 1.1.0 more convincing.

At least people now know why I’m keeping everything closed until release.

3

I offered to take the page down back in February and sent you a very polite message of explanation, since we had a misunderstanding. You did not even reply, despite me following up on it at a later time ?

The only thing my design has in common is that it uses a circle, and last time I checked, you do not own a patent on circles. And a roadmap ? A lot of projects have roadmaps, are you telling me I am not allowed a roadmap ?

MLIR.. is a bytecode. Astonishing but true! There is a even a JIT to run the bytecode that ships with LLVM.

So forget it, the page design stays. As I say, eco is an entirely separate project to what you are doing. That should really be a positive for Elm, since there can be some competition to spur on growing what is possible.

I wish you luck with elm-run.

4

When I replied here, I did not do it in haste: the last time I simply insta-quit a community of four-hundred that didn’t recognize plagiarism for what it is. I don’t blame anyone: many never experienced such a situation before. Yet, not sanctioning that behavior back then only encouraged its brazen public continuation.

This time I’m speaking up, especially to the younger colleagues here, those that might not have experienced this kind behavior before and are unsure of their moral stance on the matter.

Our profession trades in ideas. That’s the core of what we do. No offense is deeper than stealing another’s idea and presenting it as one’s own.

We savor the process of coming up with ideas, their presentation, their application… we enjoy the debate, the enriching process as thoughts are verbalized. But we respect and admire each other’s ideas. A plagiarizer trivializes the original ideas and work: it’s usually a quick, shoddy copy. It’s debasing and offensive to the original author.

To be clear, at issue here is a copy of the design, styles, content of the roadmap, and now the product positioning as I pointed out in the first message. This first happened back in February, with outright copy of the roadmap sans 0.5.0-0.9.0, accompanied by “My project is in many ways more sophisticated than Damir’s.” I agonized over that roadmap for weeks! I take pride in the result. It’s outright offensive to see it plagiarized and mutilated like that. The rest is not important: a quick skim through the repo shows and attempt at ripping things from Roc language, but I didn’t really spend time beyond that, as it’s not important at all to me.

Presumably the goal here is grabbing attention by association (“What a coincidence, I planned enterprise support for 1.1.0! Our roadmaps are so similar, we’re competing!” “It’s positive for the community to have two of us in healthy competition!”). Or maybe it was just a lazy “I need a web site, let me rip it from Damir, he already made one.”

In some circles copying something from another without permission and taking credit for it is called intellectual theft. It’s also known as plagiarizing. Academia sanctions that behavior harshly. However you diminish it to avoid moral dissonance, it is what it is: one takes from another, claims as own. The rest is just a matter of degree, but it’s not “a misunderstanding.” It’s a deliberate copy, claimed as one’s own.

Make no mistake: I have exactly zero concern about this person’s work here. I’m simply immensely annoyed by this trivializing echo behind me. Makes it unpleasant to be in the same space. Though if this happened to a younger person at the beginning of a career, it could have been very damaging.

It’s what drove a younger Evan away from public exchange of ideas. How many interesting conversations and Elm features did we never see? We lost time. The plagiarizers stole it from us. We will lose more as others learn not to present their great ideas in public for fear of plagiarizers at ready to claim “in many ways more sophisticated” copies. We will only lose. Never gain.

So no, this is not positive for Elm community.

But. It presents an opportunity to discuss this as a community, or at least have a think about it on your own. It’s at the core of what many people fear from LLMs. Here’s we have a human example as well. There are stories of “friends” grabbing people’s work from GitHub and presenting as their own to get a job over the original author. Brazen, shameless, abhorring. For me, the act here is in the same category.

This is not a good example for our profession. As a community, we must learn to sanction behavior like that.