Community BETA for Elm 0.19.1

How about rough edges around updating dependencies? Updating dependencies is not straightforward

It’s very unfortunate that for such a simple task we need external tools and/or removing cache. I once told about this to my colleague and he had impression of very immature technology. Can’t convince people that compiler is awesome if things around are not even OK.

4 Likes

Would definitely be welcome if there is going to be a 0.19.2 release…

@rupert, very interesting, thank you for running these numbers!

@jfairbank, I’ll reach out to discuss with you.

@Namek, I have done some prototyping on how to improve install/uninstall, but unfortunately it is not possible to improve everything that needs improving in one release. I think the problem you mention is well understood, but if you feel it needs further elaboration, please start a new thread.

4 Likes

I’ve been using Ilias’ elm-json:

  • elm-json install XXX
  • elm-json uninstall XXX
  • elm-json upgrade

and have been very happy with it.

12 Likes

Here are my results on a 45k+ LOC codebase, using a Ryzen 9 3900X:

0.19

$ time elm make src/Main.elm
Dependencies loaded from local cache.
Dependencies ready!                
Success! Compiled 228 modules.                                       
Done in 1.97s.

real    0m2.116s
user    0m1.433s
sys     0m0.068s

0.19.1-beta-1

$ time ./elm-0.19.1-beta-1-linux make src/Main.elm 
Dependencies ready!           
Success! Compiled 228 modules.

    Main ───> index.html


real    0m1.152s
user    0m0.915s
sys     0m0.818s

When 0.19 was released, I thought it couldn’t get any faster… Guess I was wrong! :smile:

3 Likes

On a 28k LOC (sorry, less than 50k)

0.19.0

128 modules 3.385 secs
  1 module  0.740 secs

0.19.1

128 modules 1.941 secs
  1 module  0.314 secs

       Full compile: 43% decrease!
Incremental compile: 58% decrease!
5 Likes

I can confirm on Windows 10 that the Map! bug when using --debug flag is resolved the project I work on.

Thank you so much for this beta. So happy to have the debugger back. :bowing_man:

3 Likes

Holly effin durians! I just migrated from 0.18.0 on a 51K app where changing this one critical module caused ~3min compile time. And now with 0.19.0:

Success! Compiled 197 modules.                                       

real    0m5.324s
user    0m4.845s
sys     0m0.436s

But then there is 0.19.1:

Success! Compiled 1 module.

real    0m0.158s
user    0m0.060s
sys     0m0.082s

Are. You. Kidding. Me.
What have you done, Evan!

10 Likes

I’m pretty sure I won’t have time to test this particular beta, but in the future, it’d be easier for those of us on source-based distros (like NixOS) to test betas if you publish a tag in the git repo. Thanks!

1 Like

Aren’t you comparing the compilation of 197 modules vs. 1 module? Most likely increment compilation? Or am I misunderstanding something?

Incremental is the only type that matters to me. I believe I made sure I edited just that one key module before running the compiler. That accurately describes my worst case scenario.

1 Like

To test it with create-elm-app:

  1. Inject new elm runtime
~/n/lib/node_modules/create-elm-app/node_modules/elm/unpacked_bin   
❯ mv elm elm_019
                                                         
~/n/lib/node_modules/create-elm-app/node_modules/elm/unpacked_bin   
❯ cp ~/Downloads/elm-0.19.1-beta-1-mac elm

                                                         
~/n/lib/node_modules/create-elm-app/node_modules/elm/unpacked_bin   
❯ sudo chmod +x elm
  1. Adjust hot loader
    ❯ vi elm-hot/src/inject.js # on line 35
    if (false) {
        throw new Error("Compiled JS from the Elm compiler is not valid. You must use the Elm 0.19 compiler.");
    }
  1. Change the elm version in the elm-app created project folder to 0.19.1
1 Like

Those are both for incremental compilation times. One of the big improvements in 0.19.1 is that it checks if the public API of a module has changed. If it has not changed, there is no need to recompile any of the modules that import it.

So @Birowsky is seeing it go from 197 modules to 1 module as a result of this change. There are still 196 modules that depend on the API of this one critical module, but the compiler can skip them for most edits!


Note 1: You will be able to increase the benefits of this optimization by using an explicit exposing in your modules. That way you can add new helper functions internally without changing the public API, thereby getting the faster compiles in more cases.


Note 2: This optimization also means that the worst case is improved. When an public API is changed, you must check modules that import it directly. Maybe they are broken. But you do not need to check on any modules that import it indirectly. So if your project was like:

   BigModule
    /     \
   A       B
  / \     / \
 C   D   E   F 
/ \ / \ / \ / \
................

When you change the public API of BigModule you only need to check on A and B. Their API stays the same, so you can skip compiling C, D, E, F, and everything else. So even in the worst case, it is unlikely that @Birowsky could trigger a 197 module recompile when using the new compiler.

34 Likes

Update

The BETA is not producing many reports of unexpected or buggy behavior. That’s encouraging!

It looks like the next steps are:

  1. Finish up the blog post announcing the release. I am working on that, and it is actually helping improve the error messages quite a bit. (E.g. making color usage more consistent, making errors more helpful, etc.)
  2. Get elm-test working with the new binary format of various build artifacts. There is work going on by various authors and maintainers to get that working.

Once those are both in order, it looks like it’ll make sense to do a BETA-2 or RC-1 just to be safe. There are a couple fixes and changes, so it’d be good to get some eyes on them!

Thanks to everyone who has tried out the BETA so far! Really excited about how it is coming together to make a more solid foundation! :smile:

39 Likes

That’s great to hear. If you’d make a tag in github, I can prepare a Nix package for everyone to be able to easily test RC-1 easily on macos/linux.

7 Likes

It would be nice to have ARM binaries as well.

@berend
Wait what? How would you use ARM build? You’ve set up some CI on Raspberry Pi? Are you in the beginning of this process or is it something you rely on?

I would use it on an Android Tablet to do Elm development. I tried to compile it myself, but the tablet had only 2GB of memory so that failed. Probably should have launched a bigger ARM instance in the AWS cloud to compile it, but having a ready made binary would help.

1 Like

Here’s a guide on doing it yourself. I suppose you can take the 0.19 source and take some advice from this guide? Let me know if it works out! :sunny:

@berend The Nix packages provide (prebuilt) ARM versions of Elm (I successfully use them for developing on my Android tablet). I would imagine that if the RC makes it into Nix then they will also eventually provide prebuilt packages of that there too (or if not for the RC, certainly for 0.19.1)…

1 Like