# Help planning Elm 0.19.3 release

**URL:** https://discourse.elm-lang.org/t/help-planning-elm-0-19-3-release/10911
**Category:** Request Feedback
**Created:** [September 24, 2026, 11:23am UTC](https://discourse.elm-lang.org/t/help-planning-elm-0-19-3-release/10911 "2026-09-24T11:23:37Z")
**Posts on this page:** 7
**Page:** 1

<div class="post-metadata">

### Author: ![evancz](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/evancz/32/16_2.png) [@evancz](https://discourse.elm-lang.org/u/evancz)
#### Post date: [September 24, 2026, 11:23am UTC](https://discourse.elm-lang.org/t/help-planning-elm-0-19-3-release/10911/1 "2026-09-24T11:23:37Z")

</div>

I have a potential 0.19.3 [here](https://github.com/elm/compiler/tree/0.19.3) and I need to decide if I should go ahead and release it basically as is, or if I should add more to it.

The overall project with 0.19.x releases is “get the compiler more aligned with Acadia” since that will unlock more interesting projects. (E.g. support `UInt32`, `Int64`, and other primitive numeric types. See about converting [`elm-simple-server`](https://github.com/acadia-engineering/elm-simple-server) into `server module` in Acadia. Etc.)

The actual changes here are in two categories:

1. More explicit binary encoding/decoding. The typical libraries in Haskell for binary do everything with type classes, so it’s hard to have more sophisticated binary formats without goofing up your types in your program. So this branch switches to binary encoders/decoders that I wrote by hand to be more in the Elm style, where every choice is explicit. They appear to be a little faster, but that’s not really the goal.
2. Using more precise types within the compiler. So instead of having a `Name` type for all different names, there are now separate types for module names, variable names, type names, etc. I also manage concurrency a bit differently so that crashes will get reported in a better way. I also have better computation of “minimal cycles” for whenever you have a complex cyclic value or cyclic modules.

The net effect is that it’s a tiny bit faster, the binary formats are a little different, and I can close a handful of bugs. I do not feel satisfied with the “narrative meaning” of these changes though. Maybe emphasizing that it helped resolve a couple issues. Maybe emphasizing the `type Name = Name String` approach that is possible in Elm/Haskell, but basically not doable in TS. I need to think about it more.

Which aspects of this sound more or less interesting?

---

<div class="post-metadata">

### Author: ![Janiczek](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/janiczek/32/4516_2.png) [@Janiczek](https://discourse.elm-lang.org/u/Janiczek)
#### Post date: [September 24, 2026, 12:12pm UTC](https://discourse.elm-lang.org/t/help-planning-elm-0-19-3-release/10911/2 "2026-09-24T12:12:58Z")

</div>

If the changes don’t themselves have a big narrative or exciting speedup etc., I’d maybe think of the release as cleaning up your table (a non-problematic upgrade making things slightly faster but mainly making the codebase nicer for you) so 0.19.4 or 0.20.0 can be focused on the big things. I’m sure people will be able to sympathize with that 🙂

EDIT: I’d definitely love to read something about the newtypes, ID/Name safety, primitive blindness etc.

---

<div class="post-metadata">

### Author: ![edkelly303](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/edkelly303/32/1510_2.png) [@edkelly303](https://discourse.elm-lang.org/u/edkelly303)
#### Post date: [September 24, 2026, 12:33pm UTC](https://discourse.elm-lang.org/t/help-planning-elm-0-19-3-release/10911/3 "2026-09-24T12:33:54Z")

</div>

Coool!

> I need to decide if I should go ahead and release it basically as is, or if I should add more to it.

If you were to add more to it, what would be the candidates for the next thing(s) you might add? If there’s a next thing that potentially strengthens one of these narratives, maybe it’s worth bundling up into a bigger release.

Also, I guess it depends who the narrative is for. I think people in the Elm community will be excited about the details of any new release, however small, and fixes for any long-standing bugs will be gratefully received. But if you’re looking to attract new people, I think it might be better to major on the “roadmap for aligning Elm & Acadia” angle.

---

<div class="post-metadata">

### Author: ![rupert](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/rupert/32/1775_2.png) [@rupert](https://discourse.elm-lang.org/u/rupert)
#### Post date: [September 24, 2026, 1:04pm UTC](https://discourse.elm-lang.org/t/help-planning-elm-0-19-3-release/10911/4 "2026-09-24T13:04:12Z")

</div>

> [@evancz](#):
>
> The overall project with 0.19.x releases is “get the compiler more aligned with Acadia” since that will unlock more interesting projects. (E.g. support `UInt32`, `Int64`, and other primitive numeric types. See about converting [`elm-simple-server`](https://github.com/acadia-engineering/elm-simple-server) into `server module` in Acadia. Etc.)

I think this is the narrative that is most interesting. Rather than these internal compiler changes themselves, its the goal that you are working towards that is the intriguing part. If you are comfortable making such forward looking claims.

---

<div class="post-metadata">

### Author: ![asgr-dk](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/asgr-dk/32/5677_2.png) [@asgr-dk](https://discourse.elm-lang.org/u/asgr-dk)
#### Post date: [September 24, 2026, 5:36pm UTC](https://discourse.elm-lang.org/t/help-planning-elm-0-19-3-release/10911/5 "2026-09-24T17:36:08Z")

</div>

> [@evancz](#):
>
> Which aspects of this sound more or less interesting?

I think you should save your changes for a narratively meaningful release, like you’ve done in the past 🙂

---

<div class="post-metadata">

### Author: ![then0rTh](https://avatars.discourse-cdn.com/v4/letter/t/8e7dd6/32.png) [@then0rTh](https://discourse.elm-lang.org/u/then0rTh)
#### Post date: [September 24, 2026, 6:25pm UTC](https://discourse.elm-lang.org/t/help-planning-elm-0-19-3-release/10911/6 "2026-09-24T18:25:08Z")

</div>

> [@evancz](#):
>
> 1. More explicit binary encoding/decoding.

_[goal: I’d like to learn]_  
I only ever used json and xml in elm, so I may be lacking some context, but I have no idea what this means for elm. Could someone explain please? Does it affect how e.g. protobuf works in elm?

> [@evancz](#):
>
> 1. Using more precise types within the compiler

_[goal: providing feedback]_  
I would enjoy such a blog post too. Especially if you have some insights into the limitations of TS. _(I know of two approaches to achieve this in TS: adding anything `private` to a class, or something with the `unique symbol` type. But never understood the exact type-system stuff behind them, or how reliable those approaches are)_

But if it is truly just “making the codebase nicer for you”, then we all already benefit from this change, even if you don’t release it 🙂

---

<div class="post-metadata">

### Author: ![rupert](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/rupert/32/1775_2.png) [@rupert](https://discourse.elm-lang.org/u/rupert)
#### Post date: [September 24, 2026, 8:34pm UTC](https://discourse.elm-lang.org/t/help-planning-elm-0-19-3-release/10911/7 "2026-09-24T20:34:43Z")

</div>

> [@then0rTh](#):
>
> I only ever used json and xml in elm, so I may be lacking some context, but I have no idea what this means for elm. Could someone explain please? Does it affect how e.g. protobuf works in elm?

I don’t think it affects how Elm works at all. Its just changes within the Elm compiler, which is written in Haskell, to improve how it does binary codecs - which it uses to read and write the .elmo and .elmi files you see inside of elm-stuff/ and some others too.
