Elm 0.19.1 is out!

The announcement got posted around online today:


Excited for folks to start using it!

Speed Boost

The compiler got a lot faster, but the blog post does not emphasize that at all.

This is because I’d like to set up a survey of how long 0.19.1 builds are taking on different computers and different size projects. My plan is to create a script that can measure this in a reasonable way, then share it here and solicit data from folks who are using 0.19.1 with larger projects. We need to wait until folks are upgraded to 0.19.1 though, so this will be some days or weeks in the future.

Anyway, I think it will make for a pretty interesting blog post!

Helping Newcomers

Blog posts usually cause an influx of new people, so the online forums may be a bit more active and unpredictable than normal.

I suspect there will be some frustrated folks asking questions as a new batch of people go through the learning process, so try to remember the chat tips.

At the end of the day, some folks will love the language, and others will find that it is not really for them. (Like cilantro?) That’s just how it goes!

Thank You

Finally, thank you to everyone who helped out with testing 0.19.1. This process produced a bunch of nice improvements, and I am really happy with how 0.19.1 turned out in the end!


Awesome! Also I would just like to say that I had never seen the chat tips page before now and it looks both useful and adorable!

1 Like

I love it that it compiles and it works. And that for the first time in my life I actually have success with an FP language. So language definitely has been working for me.


I’m not sure if that’s a new error but there is this small issue:

elm install rluiten/elm-date-extra - it freezes and outputs nothing.

This library is for Elm 0.18 only.

EDIT: On Windows 10

I ran this command with Elm 0.19.0 and Elm 0.19.1 on Ubuntu and it did not freeze for me. The error message has changed a bit, but that was expected.

Multi-threaded builds with Parcel now just work on Windows.
Thanks a lot :slight_smile:


Brand new to Elm and trying learn it. Going through a few quick tutorials (still based in 18) they make heavy use of toString, however as is apparent this was removed and for basic type things like String.fromInt are used. How do we do the same thing for a type alias? Or a list of some custom type? This seemed trivial in 18, not so much with 19.

Welcome to the community @Ethan_Stephens!

For running in debug mode there is Debug.toString (https://package.elm-lang.org/packages/elm/core/latest/Debug#toString) in 0.19. I usually use that or Debug.log for testing things out.

On thing to be aware of is that when compiling with --optimize calls to the Debug module are not allowed, but in debug mode it is fine.

@antew thanks for the response!

That’s makes sense as this would probably never be used on a type alias in production.

And it’s good to be learning another language!


I’ve installed Elm yesterday and tried to setup a hello world app in src/Main.elm
The first hurdle was that I would get this error message:

It requires 0.19.1, but you are using 0.19.0 right now.

I was a bit surprised that the version numbering is that strict. This was fixed by removing the elm.json file and recreating it with elm init and elm install [insert package name] to add all the dependencies as required by the app I was trying to compile. Before I figured out this solution I tried simply changing the version number in elm.json from 0.19.0 to 0.19.1, but that gave me a somewhat confusing error message that the packages could not be found and to check whether my internet connection is working. It did provide the useful hint not to edit this file by hand.

The next hurdle was that my hello world program in src/Main.elm would not compile with the command elm make src/Main.elm:

import Html exposing (text)
main =
  text "Hello!"

The error message went something like this: you must declare the module name. I was somewhat confused, since here I read, that it would be added automatically. I concluded that this might have changed and when I changed the 3-liner to the following 4-liner, it would compile and I finally had a hello world:

module Main exposing(..)
import Html exposing (text)
main =
  text "Hello!"

After that I tried to compile alexkorban/elmstatic and I faced another hurdle. When running elmstatic build, it complained that in _layouts/Elmstatic.elm and _layouts/Styles.elm no main entry point was found, so compiling failed. This is where I gave up and removed Elm 0.19.1 from my macOS and installed 0.19.0 instead. I tried the same things as described above and didn’t face any of the here mentioned hurdles.

I share my experiences here, since as a beginner programmer I really very much appreciate the effort that went into making helpful error messages. Unfortunately I won’t be able to profit from them until I become better at handling these kind of problems. At the moment I am learning mostly from analyzing examples made by others and playing around with them. As more and more things will be ported to 0.19.1 this problem will disappear of course, but I still wonder why 0.19.1 is not able to compile 0.19.0 code. Also I didn’t find any guide on any needed changes to the code to be able to pass compilation.

Thank you for the awesome language and looking forward to learning more about it!


This is a kind of guide on how to upgrade to 0.19.1

I think in it’s current form it’s missing that you might also have to change file name cases, as these have become stricter.

it seems that the travis community based elm support is broken now. actually it seems like the npm package is somehow broken

$ npm install -g elm@0.19.1
npm WARN deprecated elm@0.19.1: package.json was changed upon upload, breaking things on Mac and Linux
/home/travis/.nvm/versions/node/v10.13.0/bin/elm -> /home/travis/.nvm/versions/node/v10.13.0/lib/node_modules/elm/bin/elm
> elm@0.19.1 install /home/travis/.nvm/versions/node/v10.13.0/lib/node_modules/elm
> node install.js
Downloading Elm 0.19.1 from GitHub.
NOTE: You can avoid npm entirely by downloading directly from:
All this package does is download that file and put it somewhere.
    throw new ERR_INVALID_ARG_TYPE('path', 'string', path);
TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received type object
    at assertPath (path.js:39:11)
    at Object.resolve (path.js:1088:7)
    at module.exports (/home/travis/.nvm/versions/node/v10.13.0/lib/node_modules/elm/download.js:26:24)
    at Object.<anonymous> (/home/travis/.nvm/versions/node/v10.13.0/lib/node_modules/elm/install.js:4:1)
    at Module._compile (internal/modules/cjs/loader.js:688:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:699:10)
    at Module.load (internal/modules/cjs/loader.js:598:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:537:12)
    at Function.Module._load (internal/modules/cjs/loader.js:529:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:741:12)

ref: https://travis-ci.com/irclogs/elm-0.19/builds/132886496

I am getting the same issue, although my version of nodejs was quite old, so meaning to upgrade and try again, but I just stuck with 0.19.0 for now.

Did you raise an issue against the npm package? As far as I can work out the npm package is part of elm/compiler: https://github.com/elm/compiler/tree/master/installers. So will raise an issue there, if there is not already one.

When I set the dependency explicitly to 0.19.1-3, it worked:

  "devDependencies": {
    "elm": "0.19.1-3"

Could not use ^0.19.0 or 0.19.1.

@Damjan_Georgievski and @rupert if you look at the readme on https://www.npmjs.com/package/elm it says to "run npm install elm@latest-0.19.1", which will install elm@0.19.1-3. While this is a bit unconventional for JS versioning, I wanted to let you know in case someone else the same question. The NPM readme also suggests to only install this way if you’re not installing globally. If installing globally, use one of the elm installers from the guide https://guide.elm-lang.org/install/elm.html.

Hope this helps.

@Damjan_Georgievski @rupert
I’m not sure if you’ve seen this, but the information may be helpful:

I’ll try adding that -3 … if it was not clean I had this in .travis.yml:

dist: xenial
language: elm
elm: 0.19.1

neither did elm: latest-0.19.1 nor elm: 0.19.1-3 work in .travis.yml. The errors are on the travis link I sent earlier (I didn’t want to copy/paste parts of it, in case I miss something).

changing it to

  - latest-0.19.1

elm_test: 0.19.1

elm_format: 0.8.2

works for me https://github.com/Razzeee/htbah-character-creator/blob/master/.travis.yml

even if it’s not documented that way :confused:

Folks at https://openbenchmarking.org/ have test engine wired for some quality benchmarking.
3rd parties can easily write and publish test provile and then any user of the suite (which is free and open source) can execute command to download it and execute.
Test suite is advanced enought to handle multiple runs, warming cache, restarting computer for cold starts. Etc. etc.

Wont help with gathering input on compilation times for real life code bases, but will definetevly help gathering info on compilation time variablity between systems on some standard codebase.

Phoronix (same author) does run PHP benchmarks with it, so you can see some of the data it can gather here:

Results are uploaded to public base, where verybody can run their basic aggregations (apart from local summary of test runs ofc.).

I’m not affiliated. Just thought custom script by it’s very nature would require some of those anyway.