Elm - General Discussion, Blog Posts, Wiki

[OvermindDL1]

@cjen07

I understand that you think elm really bad and bucklescript is just awesome. However, I have some questions just on elm. To be frank, I am also new to elm. I am building my second app in phoenix and elm.

Elm is not necessarily bad, and TEA is not bad at all, just the Elm ‘language’ has…issues that I kept running in to repeatedly. Bucklescript is an awesome transpiler, but the language is OCaml of course.

@cjen07

In this app with 1982 lines of elm in 8 files, and it compiled in 453ms in total on a change (elm: v0.18). Since elm is a front-end language, I think elm files are separated like User.elm, Editor.elm or Post.elm, each communicating with backend by api individually, therefore it is reasonable to assume code in each (each part of, if you prefer architecture like Update.elm Model.elm) elm file is not too much and the compile time is linear to total code lines.

Ah still a tiny app yeah, it will compile fast still.
Compile time is not linear to total code lines, the way the Elm compiler works is it tries to ‘resolve’ a lot of paths in the type system, in some cases very inefficiently, so you have have very little code and suddenly get 15 minutes compile times (I hit one of those cases once) or have 50k lines that compile in 40 seconds (which was about the best I could get it down to without breaking up the messages a great deal more). In the ‘general’ case the compile time will increase at a small exponential, but it is a great deal more than linear (I do not think any compiler could compile in linear speed short of direct assembly or something similar).

@cjen07

If you spent over 40s in compiling the elm files in a real world project, does it mean you have approximately over 175000 lines of elm? If my theory is wrong, does it mean that when elm files are increasing, the total compile time is increasing much faster? Another question, why not test each part of elm files individually in development?

It was about 29,000 lines. And cannot test the compile time of individual files since elm compiles them in whole. Elm takes all the files and concats them into a single giant javascript file (with interestingly no optimizations performed over it). The OCaml compiler (and thus bucklescript) compiles each module by itself (after pre-generating types from dependent modules, but not compiling them) and outputs a javascript file for each module (with as many in-module optimizations possible already performed) in such a way to be trivially optimizable further by the likes of rollup or the closure compiler both). That means that by definition OCaml will always compile faster than something like Elm that output a single monolithic file.

However, elm is thinking of splitting up into multiple JS file per module like Bucklescript is doing, however they are requiring that all dependent modules are compiled first, which still makes per-file compilation linear (with in-file compilation still exponential) compared to OCaml/Bucklescript that can compile everything concurrently.

Sadly, a lot of the compile-time issues will not be able to be improved significantly in the Elm compiler because the design of the Elm language took a few very specific and VERY slow-to-compile Haskell’isms instead of the OCaml style, thus to fix those the language would have to make a couple very specific syntax changes, which are quite a radical change from what it does not.