At first it was intimidating facing a new language with a syntax that was completely different from what I had worked with before. However, as I dove deeper into Elm I was able to get over the hurdle of unfamiliarity and began to see its many benefits.
As well as being quite easy to pick up, Elm is also enjoyable to use. The tools make it simple and frictionless to develop, and the compiler makes refactoring a breeze. Some tasks that would usually take days in alternative languages can take only a day or less in Elm.
We’ve had zero run-time exceptions and fewer bugs, largely because Elm’s type system forces you to model your domain more carefully. One benefit of this is you can write code that doesn’t need tests, which increases productivity.
Here’s image of the code and one of the administration tool itself.
While using Elm has been a positive experience, there have been some hiccups along the way. Learning how to structure a large application, or at least one that had the potential to scale, proved difficult in the beginning. Eventually I found a solution that was well suited for our administration tool.
I would point out that Elm is still a young language, which requires a bit more effort than you’d expect with some alternatives. A compromise must be made between no runtime exceptions in practice, descriptive compile-time errors, an easy and robust refactoring experience and the drawbacks of having to do a bit more work. This is notable in scenarios where the requirement is so bespoke that there isn’t an Elm package available for it yet.
For now, accepting this exchange has proved successful. There is no doubt a lot more to discover in Elm that could be implemented in other areas of production at TotallyMoney.com. After all, ignoring new methods rarely leads to good things, whereas constantly evolving and experimenting will keep you in the game.