Note
This post is the first entry in a 2-part series. This one focuses on my experiences, while the next part will evaluate Gleam's readiness for adoption by companies.
For about six months now, I've been running my website using Gleam, and I recently launched surtoget.no as a side project, also using Gleam. I also had a quick chat with Gleam's creator, Louis Pilfold, who expressed that there was a lack of content out there about how it is to run Gleam in production. I'm more than happy to share my thoughts and discuss my experiences with using and maintaining Gleam code.
The sites I have might not be the most advanced pieces of software, but they are real and exist. They serve a real purpose, and they're publicly available. At the same time, I work on enterprise systems at work and have a decade of experience developing professional software. Therefore, I think it is only fair that I throw my hat into the ring and say my piece on how it is to work with Gleam in production.
For the uninitiated: Gleam is a relatively young programming language running on the Beam engine (Erlang's VM). It can also target JavaScript, but that is outside the scope of this post, as I primarily use Gleam for Beam.
What is interesting about Gleam is its relative newness. How do we know when a language is "production-ready"? What does it mean to be production-ready? (Is it enough to hit V1.0.0?). When is it safe to use a new language in production? Let's see if we can answer some of these questions.
A language is not "just a language". We have all the stuff surrounding the language, for example, we have tooling such as dependency management and LSPs. We need to be able to set up pipelines and monitor the system's health in production.
This first post in a 2-part series is dedicated to examining the language itself and how to maintain a system that should be accessible to others at all times, which happens to be written in Gleam.
I come from an enterprise background working on systems so large they cannot possibly exist within a single person's mind. They have thousands of different services, maintained by teams spread across multiple countries, all of which must work together to create an overall solution that functions as a cohesive whole (in theory).
In the world of enterprise, we don't really have the luxury of picking and choosing languages and frameworks. We're often bound to only a few options, typically chosen by a "board of architects" (often resulting in Java or C#), or limited by the technical knowledge of an existing team. When I decided to make my site, I wanted to branch out from the known into something new and different, and Gleam fit that bill.
Another aspect that I appreciated was that LLMs hadn't yet caught up. They had no clue how Gleam worked, and they still struggle. That's something I looked for as I wanted to keep my learning skills sharp and force myself to read documentation, or even the language source code, to understand how to use something.
The last reason was that I wanted to get into the Erlang VM, which has some amazing properties.
This site has been running on Gleam for over six months without experiencing any outages. Nor have there been any strange HTTP response times or hiccups. Things have only ever gone wrong due to my incompetence (which is a good thing in this case).
The site has been able to run for months at a time without my intervention or oversight, with no surprises in CPU usage, no wild fluctuations in memory usage, or any other issues. The entire system operates with a capped 512 MB memory, and it has never come close to using that (hovers around 210 MB).
While writing this post I discovered some performance issues with my websites. This was not related to Gleam, but to how I had built my site.
Performance is now great! The website can handle over 2000 requests per second on a single CPU core.
In other words, I have no worries regarding the fundamental performance in Gleam. It is fast enough to do most things. Most bottlenecks do not originate from the programming language; instead, they are often self-inflicted through poorly thought-out architecture or code.
Generally speaking, maintaining my Gleam projects has been a breeze. Gleam comes with a fairly robust package manager and build system, so updating dependencies is as simple as running gleam upgrade. In my case, I use Renovate to automate dependency updates.
If I have any criticism, it is related to the pace and immaturity of the ecosystem. Many packages have not yet reached V1, and significant development is ongoing. Some never reach V1, and some introduce breaking changes. Central dependencies, such as Lustre and Wisp, have been rock-solid; however, the minor dependencies have less certainty when transitioning from one version to the next. This has not been a significant issue, nor has it occupied much time, but it is still worth mentioning. I will talk more about this in the next post.
Writing Gleam is similar to a lot of other languages. It has a well-developed LSP that gets a bunch of new and handy features with every release. It has a robust package and build system. There's nothing that stands out as missing.
If you know anything about Beam and Erlang, you know the crazy things that VM can do, like running in a cluster, auto-scaling internal processes within that cluster, etc. When I first started building the website, I was worried that getting up and running would be similar to setting up Kubernetes. Luckily, that wasn't the case. Just as with Java, Node, and others, it is simple to bundle the app in a container and run it that way. The whole infrastructure part of Beam is kinda optional, which makes Gleam as easy to run and host as any other language. Heck, Gleam has official container images that can be used to get the application up and running.
This also means that you can easily set up CI/CD pipelines and host Gleam web applications with whatever cloud provider you've chosen (given they support VMs or containers).
Gleam is absolutely ready for production usage. Writing Gleam is no more complex than most other programming languages, nor is getting it into production and maintaining it. That might sound mundane, but in this case, that's a good thing. I don't want surprises when it comes to production. I want it to be easy without expectations.
All in all, Gleam works; it is performant, the language has been stable throughout the six months, and there have been no strange or nasty surprises. I would be happy to use Gleam in a professional capacity (and given the opportunity, I might).
In the next part, I'll dig further into the Gleam ecosystem. The language might be ready for production, but that doesn't help much if the ecosystem (or lack thereof) requires people to reinvent the wheel at every turn.
