Hi, everyone!
recently i have read through official elm guide and made some small experiments and now am very interested in starting a project in elm. I’m not new to a functional programming but i have some general questions about current state of elm:
i saw that compiler, core packages and most of community ones are several years old (and do not seem to be maintained. Is this something that you find problematic in you day to day work with elm? Other way to put it; is elm in current state viable for mid to large scale projects?
what are common pitfalls that one needs to look for when starting and working with elm?
is there official list and documentation of enhancement/feature proposals for the language?
thank you all for any feedback on this topics, and i hope for nice and constructive discussions in the future.
We are using Elm in production roughly since 2016. At this point we have around 500k LoC of Elm code, where 250k LoC are hand written and another 250k are auto generated.
Yes packages are old, but no, they are actually maintened. The fact that there are no changes means packages are very stable and don’t require maintenance. Check out this video if you have not yet. Still relevant!
For me personally the common pitfall is how to use Elm extremely simple type system to reduce amount of boilerplate produced. It’s a challenging task from time to time but an interesting one.
It is here and here as well. Basically if you like what Elm offers now it’s pretty much what it will be for a while.
So all in all Elm is very stable. It has a list of common issues that are like 10-15 and very easy to avoid. Every team member who works with Elm enjoys it at Conta AS.
@akoppela thank you for you answer, especially roadmap FAQ was very good read. It is very encouraging that you have large code base, and also how language author thinks it very much what i like as well. It is only little bit strange that there are opened issues on language that are “bugs” . IMHO feature freeze or not evolving/adding to a language is fine, not having time timetable is unusual but understandable (and i highly respect that and agree with) but not having any bug fixes for years is bit strange.
I’m also wandering can you give and example of type of boilerplate that you are dealing with?
I’ve been at Vendr for nearly a yaer now and they’ve been using Elm since around 2016. We’re also up around 600k loc with the same splits, roughly, as @akoppela. Definitely agree with Andrey as well on each point.
The only thing I’d add is that boilerplate can become less of an issue with tooling. mdgriffith/elm-codegen has worked great for me in some places and GitHub Copilot has worked fantastic in others. We use a lot of elm-codegen at work, and I use a fair amount in my personal projects. I also use Copilot at work and would happily pay for it myself if I didn’t get it through work. These 2 tools make the concerns of boilerplate mostly irrelevant for me.
Yes it’s same for use we use elm-codegen as well. We do have generated code for requests based on OAS with exception handling and encoders. Decoders are probably coming as well. As well as translations, page tree structure with router paths, images paths (base64 strings). Environment specific values. Enums from BE and some other stuff.
One important thing though I forgot to mention is that our CTO decided that for all new projects we would go with VUE or React because of hire ease of developers. Even though we never had any issues with hiring Elm developers.
I wonder if most codegen is done through using libraries that perform the generation under the hood versus using elm-codegen as a direct dependency in your project?
most of community ones are several years old
As an occasional commercial user, I get the sense that most community packages are not old and have regular periods of expansion and innovation. It may be harder to see if you just search packages.elm-lang.org vs get to know the common packages that you use daily and look through their changelogs and announcements. Similarly with build tools, the elm vite plugin is active and probably whatever new build systems emerge will get quick community plugin contributions.
one reason for my comment there that i sampled packages mostly randomly as i’m still not sure what is currently used the most. And for sure it is very nice to hear that community is still like and well.