I always liked the idea of layering things, whether in physical or digital life. One of the early examples for separation of concerns back in 1990’s is our old friends: HTML, CSS and JavaScript. Three pillars of the old and modern web for delivering digital experiences to the masses. Since my early attempts for creating static and dynamic web pages, I realized it’s not an pleasant thing to do!
The Content layer was always reasonable for me as a markup language. The Presentation and Behavior layers … was not, at least not when I read their initial history and usages. Years passed and I was switching from one stack to the other but doing all the same things over and over again without feeling a positive change in my work style. From C#/ASP.Net to PHP/Symfony to Backbone/Angular … the final results never satisfied me in case of core web technologies.
The year is 2021 and we entered the second year of COVID. I’m at the verge of changing my job and switching to a remote night-shift system administration position in a cloud provider. I got a phone call from my mentor in web technologies and we had this short conversation:
Mentor: Have you heard of Elm? Me: I know a tree by this name … Mentor: Do you like challenges like the old days? Me: I guess I do!
It’s been almost 9 month from that phone call and I happily returned to developing reliable web applications once and for all .
Back to Topic
What does Elm provide today?
Let’s return to our analogy and have a look at solutions:
Platform.worker : Create a headless program with no user interface
elm-desktop-app : The simplest way to write desktop applications in Elm
What does Elm provide tomorrow?
I’m not an expert in JavaScript runtimes, but it seems wherever we have one of those there’s a good chance of using Elm to generate that JavaScript. Here are some of the potential candidates:
I think that Elm has massive potential as a cloud language.
By exploting Platform.worker I have been able to run Elm on Node in the cloud (AWS). I also maintain a package for this elm-serverless. I also at the same time developed some Python code for an AWS project. The Python code I would sometimes deploy it then fail on a simple syntax error (sorry not a Python expert, there is probably some linter tool can help me here). I realized very quickly the advantage of very strong static type checking on cloud projects, because the deployment/test cycle on the cloud is frustratingly slow. Its a real time saving advantage if the compiler can catch as many errors as possible at compile time.
I also wonder if introducing some kind of do notation might make it easier to work with, since cloud functions are typically chaining many IO operations together.
There is a lot of experimentation going on with tools for describing infrastructure as code for the cloud. I particularly enjoyed trying out Serverless Stack (SST). It occurs to me that the kinds of DSL/builder pattern APIs we can build in Elm would also be useful there, to reduce the number of ways in which you can make mistakes in your declarative infrastructure code. If you’ve ever tried Terraform, you will know what an ugly cloud DSL language looks like.
===
Coming back to Python, people sometimes say that Elm may follow a Python-like trajectory. By which they mean the language and community might remain quite small and on the fringes for a long time, but eventually break through to the mainstream because of its quality and dedication of those that love it. Python found its niche in data science, which is surprising because Python is not an efficient language for number crunching (all the number crunching is really done by C libs it interfaces with such as numpy).
I mention this because I think we should be open minded to the idea that Elm could find its niche in an area outside of web applications, so I think this is a great topic to explore.
There is actually a (WIP?) package for writing fairly simple CLI apps in Elm. I am not the author, but I have used this package to write a simple CLI that only needed to read and write files.
I totally agree with that one, since all the major cloud providers have some kind of JavaScript SDK. Since I’m not familiar with the proprietary ones, I had a look on OpenStack SDKs and its no surprise that JavaScript/Python bindings are the most popular in the area.
In theory we could publish the OpenStack API code as a package. At the moment it only covers the parts of the API that we use.
The app also includes a rules-based orchestration engine for composing simple (but error-prone) steps into a complex (yet resilient & self-healing) process. For example:
Create a VM
Get a network
Get a port
Assign a floating IP
It’s always been in the back of my mind to turn this into a DSL for fault-tolerant cloud workflows.
.
- I feel like we should set up an Elm in the Cloud working group or something.