This Saturday I attended the Gleam programming language's first-ever conference: Gleam Gathering. A single-track, one-day event full of colour, energy, and obvious passion for the technology.
As anyone who knows me will tell you, I'm rarely outdone on the loudest shirt in the room. But at this event, I was in for some stiff competition. Lots of personality, a refreshing departure from the sea of black hoodies and black t-shirts that engineering conferences tend to produce.
For those who haven't come across it: Gleam is a statically typed language that runs on the BEAM, the Erlang virtual machine that powers some of the most reliable distributed systems in existence, and it can also compile to JavaScript. There's interest in WebAssembly and native compilation targets too, though those are further out and not the current focus. It's relatively young as a language. It's also, as of now, genuinely production-ready.
What "production-ready" actually meant in the room
It's almost been 2 years since Gleam went 1.0 - the rubber stamp of stability, signalling that it is ready for prime time.
A lot of the libraries in the ecosystem actually use Semver correctly. So you'll find packages like Lustre (web framework) at v5.6.0, prng (pure random number generator) at v5.1.0 and 🛁 Bath (resource pooling library) at v6.0.0
A key point though: the stdlib itself... not stable. At the time of writing it's at v0.69.0
A point which attendees pressed Louis on, much to the laughter of the crowd.
Louis Pilfold, the language's creator, has spent years thinking carefully about what Gleam should and shouldn't be. The result is a language with a deliberately small surface area. There's no sprawl. No features added at the edges over the years that you have to learn to avoid. You can hold the whole thing in your head, and that turns out to matter enormously when you're joining an existing codebase or bringing someone new onto a project. The code says what it means, and with the opinionated formatter, every module looks the same.
The interesting part of being early
The interoperability with Elixir is working today. Gleam and Elixir can call each other's code, which means you can introduce Gleam incrementally into an existing BEAM project rather than committing to a rewrite. That removes the biggest barrier to trying it on something real.
There's an unspoken truth I was surprised not to hear out loud during the day. Gleam may be production-ready, but the ecosystem is still forming. Normally that's the reason you wait before adopting a new technology. But during the conference I found myself thinking differently.
One person's missing library, is another person's opportunity for cementing an enduring space in the annals of language history. The libraries that will define how Gleam developers work for the next decade haven't all been written yet.
A prime example: Lustre UI, the component library for Lustre (Gleam's framework for building UIs), is in active development and moving fast, but it isn't finished. For engineers who have solved these kinds of problems before in other ecosystems, that's not a gap to be wary of. It's a genuine opportunity to shape the future of a language with a bright future. The people building Gleam's ecosystem right now are the people who will have the most influence over what it becomes.
The compiler joke
There's a running joke in the Gleam community that every Gleam developer eventually writes a compiler. In one of the talks, an engineer described how he had written an innocent DevOps tool, which took in YAML and configured application environments, and how it steadily transformed into a full configuration language. In a moment of shock, he realised the Gleam program which he had been extending, was actually just a compiler in disguise!
But it didn't stop there, they opened up the program internals and exposed a full LSP - a daunting task in any language, but here the strong typing helped ensure a graceful transition.
The pattern makes sense if you think about it. Gleam pushes programs to be highly structured. The type system, the functional style, all of it pushes naturally toward problems that look like parsing and transformation. You start working through something in Gleam and the solution takes a shape you recognise. The compiler is less a destination people aim for than a place they keep arriving at.
Some moments from the talks
Having just a single track was the right call for this first conference. When everyone sees the same talks, the conversations in the breaks have something to build on. I had more substantive exchanges in the gaps between sessions than I sometimes have in full days at multi-track events.
In one notable talk, a developer built a tongue-in-cheek Gleam application tracking Norwegian trains since they were consistently late or didn’t show up at all. In what the engineer described as a joke, he built a Lustre website displaying whether the train was delayed or cancelled.
The project picked up media attention, led to appearances on Norwegian TV and radio, and the ideas behind it ended up being raised in the country's parliament. That trajectory, from a fun experiment in a new language to a national conversation, was stressed by the speaker as one of the greatest strengths we as engineers possess. We have the ability to enact social change, to amplify our voices using our unique skillsets.
Another highlight was a deep dive from a core Gleam maintainer into optimising a chess bot, which managed to be both technically dense and genuinely fun to follow along with.
One important thing to highlight, which wouldn't have been clear from the programme is just how genuinely kind the community is. An example of this was one talk by a first-time conference speaker. He was visibly nervous and stumbled a little in the opening of their talk. The crowd was patient, encouraging, completely on board. By the time he'd found his footing, the room was with him entirely. That's not something you can manufacture. It's a sign of the kind of people the language has attracted.
The BEAM interoperability thread ran through the day in different forms. The practical takeaway for anyone on an Elixir or Erlang codebase: Gleam isn't a replacement, it's an option. You can reach for it where the type system helps and stay in Elixir where you don't need it.
One thing which came up less than I would have expected is AI coding agents. The general feeling was actually one of skepticism towards AI tooling of this kind. Sure, attendees I spoke to were using LLMs to assist with learning and assisting with prototyping. But in the Gleam world, they don't seem to be fully bought into the drastic change which seems to be undergoing other ecosystems and languages.
The issue isn't that Gleam is too complex for agents to handle. If anything, the opposite is true, the language is small and clean enough that a human can learn it in a weekend, and that same simplicity should extend to AI. The real constraint is training data. Gleam doesn't yet appear in enough codebases to give the current generation of models much to work with.
In my own experiments with Gleam encoding agents I found them to actually work pretty well, surprisingly. They could even reason their way around the use statement (probably the most confusing language feature for newcomers).
When it comes to branding, Gleam's visual identity is unusually strong for a language at this stage. Lucy, the pink star mascot, is genuinely memeable in a way that most programming language mascots aren't. Stickers were everywhere on Saturday, in all kinds of variations, and the pink carried through everything from docs (they use a rebranded Hexdocs for library documentation) to conference materials. It sounds like a minor thing, but identity matters for community formation. People wear their Lucy stickers with a kind of affection that's hard to manufacture. Many folks were highly impressed by the bright pink Lucy socks one attendee was wearing.
The funding question
One conversation that deserves more than a passing mention is Gleam's funding model. Louis is full-time on Gleam, but there are four core maintainers, and right now only Louis is able to work on the language full-time. Getting the rest of the core team to that point is one of the most important open problems for Gleam's long-term health, as stated by Louis himself.
What struck me about how this came up on the day was the tone. People weren't just nodding along to a sponsorship pitch. Members of the audience were actively asking how their company could pay Louis directly for continued development, rather than relying on a donation model. That's a different kind of conversation. It suggests people understand that Gleam's future depends on solving this, and they want to be part of solving it.
Gleam has no corporate backer. It's built entirely by individuals. That's also part of what makes the community feel the way it does, but it means the sustainability question is real, and it's worth paying attention to.
It's worth noting that Alembic has been sponsoring Gleam for years now because it's important to us that the language and its ecosystem have a sustainable future. When you depend on open source, and especially on a project driven by individuals rather than a corporation, sponsorship is an investment. We want Louis and the core team to be able to keep doing the amazing work that makes Gleam what it is, and we'd encourage any company building on the BEAM to think about what that's worth to them.
What this means for us at Alembic
At Alembic, we build the Ash framework, so the BEAM isn't just something we're comfortable with, it's what we work in every day. We already live with the benefits of the runtime: fault tolerance, concurrency, the kind of reliability where whole categories of production failure simply stop being your problem.
Gleam sits right at the intersection of things we care about. It brings strong static types to the BEAM, which appeals to us on its own. But Lustre also provides a genuinely compelling alternative to Phoenix LiveView for server-driven UI and rich client-side interactivity, with the full type safety that Gleam carries throughout. For a team that already thinks carefully about the front-end, that's a meaningful combination. We haven't shipped anything in Gleam yet. But the Lustre component library is the obvious next piece that the ecosystem needs, and building component libraries for type-safe UI frameworks is exactly the kind of problem we've spent years working on in other contexts.
I'm planning to spend some time in the coming weeks building something real with Gleam, something with enough substance that it pushes against the edges of what the ecosystem currently offers. That's the fastest way to learn where the gaps actually are. And if I end up writing a compiler along the way, well. Apparently that's just part of the process.
