A Short Story
The year is 2008...
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:
elm-bootstrap : Responsive and reliable web apps with Elm and Twitter Bootstrap
elm-css : Typed CSS in Elm
elm-ui : What if you never had to write CSS again?
What does Elm provide tomorrow?
So, what do you think of Elm’s present and future capabilities? I’d love to hear from you
I think that Elm has massive potential as a cloud language.
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.
That seems nice, but lacks some documentation goodies. Maybe @albertdahlin have more resources for us .
My guess is the docs are lacking because it’s a work in progress. I’d be happy to help with questions about using it if you have any.
Compiling to web assembly (for serverless / cloud) is the big growth area I see
We built an OpenStack client in Elm:
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.
P.S. Our orchestration engine implementation was inspired by a paper posted here: Intents and Facts - pondering CQRS in Elm - #3 by MarkHamburg
Nice work - I feel like we should set up an Elm in the Cloud working group or something.
That’s in interesting project! I’ve been away from infrastructure services for 2+ years but can clearly see the potential on such projects
I don’t see any #cloud in Slack. It could be a good starting point
I love it. Great to have well done real world Elm projects open sourced.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.