I have a potential 0.19.3 here 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 into server module in Acadia. Etc.)
The actual changes here are in two categories:
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.
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?
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.
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.
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.
[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?
[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
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.
I think that a small release now would do good to keep up the momentum. It would provide a pulse for the project, for it to appear healthy. Doesn’t hurt to also promote Acadia, which was released after the previous Elm version!
The most exciting things are possible after the Elm and Acadia compilers are lined up, so perhaps it is possible to use this sort of diagram to make the incremental steps more interesting?
Tereza and I also identified three potential stories before Acadia alignment:
Nicer error messages at “faster type inference”. I can keep record field order much longer now, and the rendering for record mismatches is better. (It’s already improved in Acadia, so you can preview it there.)
Faster compiler at “faster DCE”. It should be a fairly noticeable percentage since code gen is currently sequential, and I believe it can be made concurrent.
Faster applications at “faster Elm code”. I don’t know if it’ll be that crazy of a percentage on DOM benchmarks, but it’s at least a topic that JS people have historically cared about.
I think the dependency graph is interesting in itself and gives people a real idea of where things are going and what the goals are. I think if you used it as a basis for an initial blog post with 0.19.3, then you could subsequently do smaller releases that are maybe not super exciting in themselves, but are clear milestones on the way to completing the whole graph. I think people would enjoy following along with that, especially if you update the image of the graph in each release post to show the progress - it’s like unlocking a tech tree in a video game.
(Also… this is possibly a heretical opinion and just my two cents, but: having a fast compiler is awesome and the insights on how you are making it faster are going to be very interesting, especially for compiler people. And the final goals after the Acadia alignment are extremely exciting! But in the shorter term, for the general Elm user, the experience is that the compiler is already super fast, and I think possibly the most impactful short-term thing in the graph for people who are developing web apps might be the new experimental virtual DOM, because it fixes real-world issues with browser extensions.
Releasing the new experimental VDOM as part of the smaller releases before Elm 1.0 might also be good to give people time to try it out and find any bugs or performance issues before the big 1.0 release. And if it turns out to be a bit slower than the current VDOM, then maybe the compiler improvements that make the runtime faster will compensate for it.)
Thanks. This tells a story in a more interesting way than a conventional bullet point style roadmap. Not sure what “precise names”, “fields” and “symbols” really are, sounds like some String interning work or maybe putting synthetic ids on parts of the IR to enable various optimisations - “faster type inference”, “faster dce” ?
The interesting one for me is Int64/UInt64, as eco is already doing Int as signed 64-bits, and I think maybe Acadia has a few more number related differences to Elm. Its helpful to know that Acadia is the language target that Elm is moving towards.
I don’t think having a story is particularly important for patch versions. Typically I think of them as more under-the-hood changes, and if you feel they have reacher a particular milestone, it’s ok to plant a flag there.
But if you do want a story, personally I feel the Acadia alignment is the most compelling – it tells me where things are going.
Thank you everyone for the feedback! I found a good story for a 0.19.3, so I am currently building binaries. I’ll try to get prerelease binaries out later today, and then plan for a public release next week.
