A list of companies using Elm in production
github.com
github.com
The biggest upsides in my view are:
- The compiler is your best friend, the error messages are great, and you can enforce a lot of things with the type system. Have a list that should never been empty? Use a NonEmptyList, need to manage a selection? Use a Zipper/SelectList. Forgot to handle a possibility in a case statement? The compiler will catch it for you.
- Refactoring, even large scale refactors, are tractable and actually fun. Change the architecture in whatever way you want and follow the compiler errors, when you fix the last compiler error things usually work like you want!
- (Almost) No runtime errors. There are still a few rough edges where you can get a runtime exception, but they are uncommon.
It is not to say it is all roses, there are negatives as well:
- Lack of a roadmap or timeline, there is zero visibility into what is being worked on and when things may happen. This has been a deliberate choice by the core team I think because when they had a roadmap and parts of it didn't fit into the next release people were angry.
- Bugs can take a long time to be fixed, even if there is a PR that fixes it, it is unlikely to be merged.
- Experimentation is discouraged. The 0.19 update removed the undocumented, unsupported, here-be-dragons hooks that allowed writing effect managers except for repos in the elm or elm-explorations organizations on github. I agree with not allowing those modules to be published to the elm package site, but intentionally blocking people experimenting on their own is unnecessary in my opinion. Of course you can always fork the compiler and remove the restrictions.
- Ports are a pain. We generally use custom elements in place of ports where it makes sense, but they are really a hack around some of Elm's pain points, if I could do it all nicely in Elm I would.
this is a bit sad (the fact that mobs are still mobs)
in any case I wonder if they couldn't make some kind of core partner club with people that have been long and deep Elm users
Also there is a core Elm team consisting of something like half a dozen people, unless you mean a partner club of e.g. tech teams that use Elm.
I have an immense amount of respect for Evan Czaplicki for how he tries to thread the needle here and the huge amount of thought and craft he puts into the UI and UX of Elm to make it accessible. Unfortunately you can't please everyone (hell he doesn't even please me with all his decisions, the gall of him! ;)) and Elm has had its share of vocal naysayers. Elm may or may not die out, but the impact it's had on raising the bar for the UI/UX of dealing with a compiler has been IMO one of the most valuable advancements for statically typed languages in recent years.
You still can't write a generic sort function. It's not only typeclasses, there's also no module system and Evan is patronizing about it.
Not that people in open source can't be entitled, but the way Elm handles the community is awful and patronizing. Also they make too many breaking changes for me to write code in Elm.
I'm curious what your problem is with ports? In my experience it's a nice API for interacting with the outside world. Or are you referring to DOM features that haven't been mirrored in Elm yet?
For instance, we have a text editor that wraps Quill so that we can support things like mentions, hashtags, and emojis. We can have multiple instances of the editor on the page at once, so the port needs a way to uniquely identify which instance the event is for, and handle delivering any responses to the correct instance of the editor. I find it a lot easier to partially apply the ID of the editor to the message so that everything is defined where it is used in the code. It is also possible to forget to add the necessary subscriptions when adding the editor to a new page, whereas with a custom element it is all handled internally.
Another case where ports had a bit of an impedance mismatch is on using existing browser APIs, like the Intl module (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...). We wanted to use it to format an epoch time into the user's locale. The only way to call the Intl module from Elm itself is through ports, and the wiring makes the code a lot more complex because you have to send the request out through a port, wait for the response, and then render it. With a custom element it becomes a lot simpler conceptually, we have something like
DateTime.view posix
InfiniteScroll.view
{ onScrollIntersect = LoadMore
, state =
case feed of
Done ->
InfiniteScroll.Done
Failure ->
InfiniteScroll.Failure
Loading ->
InfiniteScroll.Loading
}
I don't know if there is a formal name for this pattern, but we've been calling in the "un-attr" pattern, you define an opaque type like
type Attribute msg
= Attr (Html.Attribute msg)
math.js has a nice `math.evaluate` function for this, that in theory would have the type `String -> Result ParseError Float`, if I could directly assign Elm types to a JS function. However, I can't actually use the function like that. I must treat it as a pub-sub mechanism and define the requisite messages, state, update functions, etc. in order to use it. This turns what should've been a one line call into potentially dozens of lines that also forces an architectural change in how the calling code actually calls the function.
The only other real alternative is to rewrite the functionality I need in Elm.
There should be some built-in asyn request/response mechanism for ports, in the style of the Http module where you specify a Msg for the response. This would work for synchronous stuff too.
As far as I can tell the only reason Evan doesn't include something like task ports is to purposely make interop less convenient (but no more safe) than it needs to be, in order to encourage people to write elm. However, I think this decision will end up biting him at the end of the day.
But where we used to have only 1 european conference in 2017, there are now at least 3. The list is still short, but growing and there is no crazy push for adoption so it's understandable.
Most of the core libraries haven't been updated for over 2 years, which is OK, since they work :). That's something that is quite far from the 'there has to be noise about it' habits from our tech world, and it might be one of the reasons it doesn't raise.
I still love writing it more than anything else. Elm makes me happy, more than anything else I've ever written, and that's all the counts for me
I certainly have overall positive feelings about it, with some frustrations (like any language really). I’ll say that the most stand-out thing about that code is that I can be off it for six months, come back to it and within an hour or so I’m back to comfortably knowing what’s going on.
I’d played around with functional languages before Elm; I’m a bit of a language nut. One thing that’s easy to forget is how intimidating the syntax can be to people who haven’t seen anything like it before.
I don’t know that I would do such a large project in Elm again though. Or at least, it’s not something I’d push for wider adoption within work; some has to do with factors like finding developers and fact it’s just really early days for the languages in the grand scheme of things. It needs more time to grow.
On the technical side, having subpages and doing the routing of messages can be really painful and I don’t really like the ‘huge flat data model’ approach. I abstracted the core routing boilerplate away by using a JavaScript templating library to make a boilerplate generator. You specify the screens you want and your main.elm gets generated from a template, with the appropriate message routing and handling for update and view calls and the structure of the top-level data model being generated for you into an Elm source file that actually gets compiled. it worked out for us, but I still feel like it’s working around a shortcoming of the language.
It's something between Elm and React (while actually using React as a platform) with a lot of built-in functionality like routing, styling, data storage and more.
If I may ask a question about syntax... Mint `render` returns look so very close to JSX syntax, but slightly different. It appears bare text variables are annotated `<{ varName }>` rather than `{ varName }`, and the `<Component::style ...>` syntax is unfamiliar. What is the motivation for providing a syntax so close to JSX but slightly different?
Do we have a list of pain/frustrations in the X language/framework based on hand-on experience?
People and language/framework experts could share their advice and suggest better ways.
We finished it on time, which is already uncommon and especially when you don't have any real prior experience with a new language. We shipped it to production, and it has been working flawlessly!
The simplicity of Elm fundamentals make the language easy to learn, your code readable, and the solution to your problems almost obvious. On top of that, the "If it compiles, it works" feeling helps you trust your code and prevents most of the bugs introduced in refactors.
We aren't going back any time soon :)
(This link takes you to public channel 1) https://cb.virtualairwaves.com/channel/1
More information here: https://virtualairwaves.com/
On the other hand, I have been using Elm for solid 4 years, and there are so many moments of Pure Joy of working with Elm, that JS/TS is unbearable.
I have dropped many offers to work on React TS codebases, because that kind of language is such a downgrade after Elm ... IMHO
I ... don't think that's true?
There are lots of "superior" technologies that just haven't won. e.g. the handful of people who use it _swear_ by Datomic. And there are load of so-called "inferior" technologies that are still widely relevant. Mysql? Php? Wordpress? They pay a lot of software developers' bills.
I work at NoRedInk, and we pay Evan Czaplicki to work on elm. When we started to migrate to Elm, our eng team was under 10 people. Larger companies, e.g. even NoRedInk today, tend to be less agile.
This is not my experience at all.
I'd use PureScript next, or maybe ReasonML.
Elm is stagnant and its dictator seems to be quite insistent on keeping it that way.
1. Development of compiler and core libraries strictly BDFL driven (at least used to be)
2. Fixing some important compiler/library bugs takes years
3. No way to host private package repositories
I still use Elm personally, although these are very valid concerns.
4. The language is still unstable. Porting our code to the next release could be a huge task.
5. Elm + JavaScript is generally painful.
6. Few libraries, some of them unmaintained. Combined with the near-impossibility to use JS libraries from Elm, it would increase our work too much.
I would never use such a thing in production.
Getting rid of kernel modules for everything others than core packages in 0.19 made JS <-> Elm interop even more painful and broke some apps. I forked the compiler [1] to support that, although it is not upto date (still stuck at 0.19.0)
That's kind of related to the dictatorial community management. Relatedly, you still can't write a generic sort function.
On that note, it's interesting that publishers have already put out print books.
'If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.'
To a significant part of the community 1.0 means a stable API with considerations of backwards compatibility.
I know many people aren't using pure semver but the implications of a 1.0 have in my opinion extended beyond that point and beyond semver in general.
But was it a well-known list before this? I hadn't seen it, and know of a few projects that could have been on there.
What I'd like the list to include, though, is some references to the companies discussing using Elm. Pros and cons, the scale to which it is used etc. For instance for Vy there is this blog post: https://blogg.bekk.no/using-elm-at-vy-e028b11179eb
- yearly updates in the official blog - it's very hard to convince a team when it smells like abandonware - besides not being. The fact that the language has a single centralist owner does not help (just look at the blog posts, it's always "I did this, and that", not "we".
- active work from the owner to shut down another PKG manager (Pine, if I recall correctly), because it allowed usage of """kernel""" modules
Yes, but a minor point I'd like to make is that because of how Elm is organized, you just put stuff in your src folder and it immediately compiles (since there's no JS FFI etc.). So it's not as big of a pain as it might seem.
I'm currently not in the position to do a pull request.
Should I take the list with a grain of salt? Just kidding, I'm just curious which they think is the first.
I'd try PureScript next, or ReasonML. But not Elm. Definitely not in production.
1. It comes with an opinionated architecture for building apps (model, view, update loop): https://guide.elm-lang.org/architecture/. This constraint is a breath of fresh air if you've ever installed React and then been stuck wondering how you should deal with state. Mobx? Event emitters? Redux? And your app increasingly niches itself into a novel constellation of dependencies. Meanwhile, Elm apps are basically all the same from an architectural standpoint.
2. Strict type system, great compiler errors, no runtime errors. I think the best illustration of this is refactoring power. I've come back to old projects where I certainly don't remember how the code works. I start writing the code that my feature needs (like changing the html to rely on variables I haven't yet defined) and I basically just follow the compiler errors until it works. Or I've made massive refactors like added an archer class to my game that was previously just melee classes which introduced daunting modeling changes to my system, and the compiler essentially gave me a TODO list of all the code sites I needed to update.
Elm certainly involves learning new things, but there's also a lot of work in stitching together a similar concoction of React, Typescript, immutability, etc. In many ways Elm is a vast simplification.