Over the past year or so, I’ve reluctantly come to the conclusion I need to leave Elm and migrate to some other language (most likely Bucklescript via philip2), and I definitely cannot recommend it to anyone else. This post is about my reasons for that, which are mostly about the way in which the leadership behave.
If you are considering picking up Elm, it’s worth reading this cautionary tale first. Keep in mind that it is one person’s perspective, and there is always more to the story. That being said, this is not an angry rant, but a long, deeply thoughtful criticism of Elm’s community.
This release and associated announcement post came back in October, but a) I must’ve missed it, and b) it’s conceptually cool enough to share even now. Evan Czaplicki:
… with the release of Elm 0.19.1 today, I am excited to share the new and improved syntax error messages! My hope is that the new compiler feels more like a teacher, showing helpful and relevant examples when you get stuck.
The remainder of the post shows some examples of how this looks in practice. One aspect of this that is odd/interesting is the compiler uses first-person perspective. It says things like:
Declarations always start with a lower-case letter, so I am getting stuck here
I was partway through parsing a record type, but I got stuck here
Maybe it’s always done this, or maybe this is new? I dunno, but it definitely makes it feel a whole lot more personal and friendly this way. Evan and the Elm team are really pushing the world of language compilers in a great direction. I’m excited to see where it all leads.
A desktop Kanban board app built with Elm and Rust. How do they do it sans Electron?
it uses native WebView (WebKit for Linux/macOS, and MSHTML on Windows)
For more details see here. I’d love to see how this app performs in terms of memory use when compared to an Electron-based version. How big are the wins? Is the trade-off worth it? Sounds like great fodder for blog post…
Zack Kayser built a Texas Hold ‘Em app with the EEP (?) stack and wrote up his findings. He calls Elm and Elixir “a match made in Functional Heaven”, but the endeavor wasn’t without its challenges:
I personally struggled with 1) how to organize my code, especially with larger modules, 2) figuring out how to make the UI more interactive, and 3) sharing code across modules.
Our world is full of uncertainty. This uncertainty bleeds into our programs. A common way of dealing with this is null/nil. Unfortunately, this leads to even more uncertainty because this design means any value in our system could be null unless we’ve explicitly checked it’s presence.
Imagine how many developer-hours are wasted globally each year dealing with null/nil. The number would probably astound us.
The major advantage of guard clauses is to suss out invalid inputs (often nils) at the perimeter of your program/module/function, so the rest of your code doesn’t have to concern itself with these uncertainties. But
Maybe there’s another way…
In Elm, all values are guaranteed to be present except for those wrapped in a Maybe. This is a critical distinction. You can now be confident in most of your code and the compiler will force you to make presence-checks in places where values are optional.
Click through to learn the mechanics of it all.
Run Elm on the server, via Elixir. Interesting idea…
A few months ago I learned of Elm, which claims to be “the best of functional programming in your browser”. After inhaling the documentation and watching a few videos and talks, I started tinkering myself and quickly fell in love with Elm and the feeling it gives me when writing code in it.