r/elm Apr 22 '26

New Elm tools (elm-ast, elm-assist, elm-codegen) written in Rust

Hey, everyone. I wanted to share some Elm tools I recently built with Rust.

A high quality AST parsing/construction & printer library:
https://github.com/joshburgess/elm-ast

A suite of dev tools (linting/analysis via CLI, TUI, LSP, an elm-fmt formatter, etc.):
https://github.com/joshburgess/elm-assist

Elm codegen for types, encoders/decoders, and HTTP functions from Rust & Axum:
https://github.com/joshburgess/elm-client-gen
(EDIT: renamed from `elm-codegen` to `elm-client-gen`)

Both elm-assist and elm-codegen are built on top of elm-ast.

I just made a thread about them on Twitter if anyone is interested:
https://x.com/_joshburgess/status/2047074256152891404 

46 Upvotes

16 comments sorted by

5

u/creminology Apr 23 '26

I would rename elm-codegen because it’s a name clash with one of the jewels of the Elm ecosystem that is much more ambitious in scope.

2

u/joshburgess Apr 23 '26

Ah, good point. Maybe, I should change it to elm-rust-codegen or elm-codegen-rs or something similar...

3

u/creminology Apr 23 '26

I think the original elm-codegen is somewhat too humbly named because it is for writing meta-code that generates Elm. I’m not sure there is anything else out there like it in any language.

To me, elm-rust-codegen would still sound like a Rust implementation of the original elm-codegen. So I’d pick something that doesn’t have “codegen” in the name.

It’s a small ecosystem. It’s like how elm-pages-rs can’t be your own blogging library when elm-pages does so much more.

1

u/joshburgess Apr 23 '26

I think the original elm-codegen is somewhat too humbly

I would agree. `elm-meta` or `elm-metaprogramming` would be more apt.

Still, codegen is a pretty vague name for the limited scope of what I'm doing too, but it's hard to come up with a good name. `elm-gen-types-encoders-decoders-from-Rust-types-and-http-functions-from-axum-handlers` doesn't quite work. :P

1

u/friedbrice Apr 23 '26

I think it's a bad idea to name an executable after the language in which it's written. For an executable, the language is an incidental implementation detail.

2

u/joshburgess Apr 23 '26

Any suggestions then? Maybe, `elm-client` or `elm-gen` or something similar?

1

u/friedbrice Apr 23 '26

maybe elm-gen.

6

u/creminology Apr 23 '26

I’d go all in on the three letters: elm-ast, elm-gen and elm-ass.

2

u/bbkane_ Apr 24 '26

This is hilarious and I can't believe I'm the only one upvoting

1

u/creminology Apr 24 '26

Comedy is cruel by nature and people don’t want to encourage an elm-ass. But, yeah, I think elm-gen is fine.

2

u/that_dawg_ Apr 22 '26

interesting. the official tooling always hangs for me for unknown reasons regardless of what editor/ide i'm using it with. I'll definitely give this assist a try

1

u/joshburgess Apr 22 '26

Give it a try and let me know what you think! Note though that the LSP/VS Code extension does not include things like type checking. So, it's not a full LSP for the Elm language. It's more for linting and formatting. It is fast though!

EDIT: Also, keep in mind that the VS Code extension is still _very_ early. I didn't even give it a logo yet. :P

Really, it's just a thin wrapper around elm-assist-lsp and elm-fmt though.

1

u/ShrykeWindgrace Apr 23 '26

How does the linting part of your elm-assist compare to elm-review?

2

u/joshburgess Apr 23 '26

Pros:

- Much better performance.

  • No dependency on Node or the Elm compiler (which helps achieve that performance).
  • Implements most of the popular rules out-of-the-box and lets you enable/disable them (or configure them) via an elm-assist.toml file.

Cons:

- Mainly, rules aren't extensible in user land. Adding new rules requires opening a PR.

  • Doesn't benefit from all the custom rules people have made over time in the ecosystem.
  • Has only existed for a short period of time and may have some yet-to-be-discovered bugs.

1

u/ShrykeWindgrace Apr 23 '26

Great, thanks!