If you like what you see now, that’s pretty much what Elm is going to be for a while.
I’m currently doing some exploratory work. It is still too early to tell which parts of that might work out, so there is no real news to share at this point.
If this works out, even in the wildest version of success, I wouldn’t expect the language or core packages to change very much. Maybe two or three years down the line it could reveal something that’d be good to fix up, but I don’t really foresee notable changes right now.
If this exploratory work does not work out, I have some more conservative projects that are good ideas that I want to circle back to at some point. Things like:
- add a constrained type variable
eqto get rid of the runtime error for(==)on functions - try to integrate
elm testso it can run only tests that changed - try to get
elm formatusing the latest parsing infrastructure so it’s not a perf bottleneck during development anymore - do another round on perf because I have one last idea that can squeeze out a bit more speed
These are all nice quality of life things, but with 0.19.0 and 0.19.1 taking so long, I got pretty burnt out on “incremental improvements that are good ideas, but take a very long time and aren’t very exciting to non-Elm users.” Without getting too into the details, I really needed to change things up before returning to these particular ideas.
Taking a step back, I find that working on what is interesting gives the best results, so this may change as new things come up in some exploration. For example, all the error message work in Elm began as a project to implement the --report=json flag. That work happened to reveal some cool ideas on improving error messages, and if I had been using a rigid roadmap, I might have skipped those ideas to meet the publicly-stated arbitrary deadline. We’d have a roadmap, but error messages no different than other type-inferred languages.
I think having more flexibility in planning is a major competitive advantage for Elm, but obviously it is a trade off that does not work for everyone. If someone needs more certainty, I generally recommend looking into other languages to see if they have a balance that works better for their needs. For example, languages made by big corporations are generally “less risky” on things like this, but I think you see the fruits of that kind of process in the design decisions as well. Trade offs!
Anyway, like I said at the beginning, if you like what you see now, that’s what it’s going to be for a while. Even in the best case scenario with my current explorations!
I hope this is helpful information, and I hope you have a good experience with Elm, even if you ultimately find a different language that works better for you!