Pre-release for Elm 0.19.2

Request Feedback
1

Please do not post around other places yet! There may still be little bugs to fix, so it’s not “live” until the blog post goes up on elm-lang.org and the binaries are posted on github.

I am hoping to do a public release of Elm 0.19.2 next week, so I want to do a bit of a pre-release period beforehand so that people have a chance to test things out.

Draft of Announcement

I am trying to just get back to making releases and not be too precious about it. So here is the current draft:

Road to Elm 1.0

I have a lot of compiler improvements piled up, and the road to 1.0 is essentially to incorporate them into Elm in a sequence of small releases. The release today is a little compiler performance improvement to just get things started, and I hope you will give it a try!

Faster Builds with Elm 0.19.2

I love a fast compiler. So many powerful corporations are competing to waste my time, and if you give them a second, they will show you some statistically optimal “content” and try to take as much time as they can. So I like my incremental compiles to take <400ms so there is no time to switch away to something else.

So I was very happy to see that Elm 0.19.2 compiles 850k lines of Elm code from scratch in 5.7 seconds, and then takes <350ms for incremental builds. Nice! My compiler can help me stay focused and happy with my work!

The actual improvements in 0.19.2 are focused on allocating a little bit less during parsing. For the 850k lines I was experimenting with, I saw:

  • 20% lower copying in GC
  • 10% lower peak memory usage
  • 7% faster overall

In other words, spending less time in GC makes things faster! Who would have guessed?! So for programs over 500k lines, you may see a modest improvement. For smaller programs, you will just see that the Elm compiler continues to be very fast!

In real world testing, results ranged from slight improvements to a 1.9x improvement when compiling 351 modules: from 4.981 seconds to 2.595 seconds for compiling from scratch. So I am curious to hear if those of you with larger projects will notice any change!

What is Next?

As some of you may know, I have been working on a database-related compiler called Acadia for a while. That work went really well! It is currently in private alpha, and I am excited to share it publicly later this year. In doing all that work, I figured out a bunch of compiler/language ideas that are useful in Elm as well. Some are simple performance things (like the faster parser) and others are more visible features like equatable types. To get these ideas integrated into Elm in a nice way, it makes sense to do a series of small non-breaking releases, and then go 1.0 for the final touches.

Draft of Binaries and Installers

Here are the installers:

And here are the binaries:

I have tried to sign and notarize the Mac installer and binaries. The Mac installer also provides a “universal binary” such that it’ll work on ARM or x64 by default. (Basically a binary that includes both instruction sets, so it just jumps to the appropriate instruction set for a given computer.) So please let me know if you notice anything related to signatures, notarization, permissions, etc. on Mac!

Note: If you are getting the binary file directly, you’ll want to extract it like this:

gzip -d elm-0.19.2-linux-x64.gz
mv elm-0.19.2-linux-x64 elm
chmod +x elm

Requests

Please give it a try, and let me know how it goes on Discourse or on Slack!

It should work 100% the same as compiling with Elm 0.19.1, just a bit faster. So please let me know if you notice anything that looks like a regression or breaking change.

I am also curious about the signed/notarized binaries on Mac. I guess it should just go smoothly if everything is signed properly, so let me know either way.

37 Likes
2

Nice work!

One piece of feedback on the announcement. For me, the sentence about loving a fast compiler because corporations are trying to turn you into a brain-dead moron is too much of a non-sequitur. After reading the next sentence, I got the point (I think?), because I know that there are studies that show that if something takes more than X seconds, people will switch to another task instead of waiting, and I also know something about the “attention economy” (in the context of social media etc). But if a reader is unaware of either of those topics, I think it might be quite difficult for them to follow your train of thought.

1 Like
3

I was struggling to get that sentence right, but it just wasn’t quite working! Here’s a toned down alternative that is probably clearer:

I love a fast compiler. So many powerful corporations are competing to waste my time, and if you give them a second, they will show you some statistically optimal “content” and try to take as much time as they can. So I like my incremental compiles to take <400ms so there is no time to switch away to something else.

I don’t think it properly captures my full emotions for the companies that do this, but it’s probably better nonetheless.

Note: I edited it in the original post as well, so apologies to people confused by reading these two comments. The draft announcement used to be different!

5 Likes
4

Congratulations on the release Evan! Very exciting to see.

I would love to read the changes to the compiler. Perhaps there’s something I can learn from for my own compiler in that diff. Will the source code be published when the the new release officially goes live?

5

The compiler code lives on GitHub here, so you can find the commits there as always. I just haven’t put the final 0.19.2 tag on yet in case there are any more little mistakes to fix.

1 Like
6

Ah! Lovely. Thank you Evan.