In a world of ever-expanding programming languages packed with features, the Gleam programming language takes a different path: it chooses to stay small, focused, and resolutely practical.
This philosophy extends way beyond the language’s design itself encompassing tooling, ecosystem, and how Gleam itself is developed.
Being a truly open source project, free from corporate ownership, Gleam has to be really efficient with its resources: any new feature must justify its place, not just in terms of usefulness, but in terms of long-term maintenance.
This is also what allows Gleam to be independent and community-driven, similar to many of the Linux community software projects we know and love.
Speaker Bio
Giacomo Cavalieri
Giacomo is a software developer and a functional programming enthusiast.
Upon discovering Gleam he couldn’t help but fall in love with the language and its friendly community.
He’s now a member of Gleam’s core team and an active contributor to its compiler’s development.
Gleam keeps the language small by saying no to features. What is the most difficult feature you have had to turn down or remove, and why was it the right choice for the long-term health of the project?
You highlighted how a small team of 3 people is mostly in charge of Gleam (apart from an amazing contributor base). What is Gleam’s stance on LLM-assisted programming (in case it has one)?
Jak answered this, but I thought I’d give my perspective too. In 10 years I’m hoping to see Gleam continuing to be sustainable in terms of community and financially, so it can continue to be a reliable foundation for it’s users in the 10 year after that, and beyond! Additionally, I would love to continue to see people taking great joy working with the language and in the projects they have with it.
In the early years it was a challenge to not get caught up in the excitement of cool new features, but over the years I’ve become so convinced in the small-and-cohesive approach to design that I don’t feel any longing for anything in particular. I guess the difficulty in reality is convincing folks that the absence of delightful $FEATURE from their favourite language may not actually be a problem!
It’s a general purpose programming language, so folks use it for lots of things, but networked programs such as web applications is a very popular sort of project. Gleam’s most commonly used runtime is the Erlang’s BEAM, an extremely powerful virtual machine optimised for massively concurrent low-latency and fault tolerant distributed programs. Famous for being the engine behind WhatsApp. That runtime capability certainly helps.
Gleam can also compile to JavaScript, so a lot of folks make applications that run in a browser, often using the Lustre UI framework.
We don’t have any formal policy yet, in part due to that not being an effective use of our time currently. In the last couple months we’ve started to have some amount of increased workload dealing with AI generated messages and contributions, which as been frustrating. If it gets further worse in future we will have to take some time away from development and maintenance and devise some solution.
We’ve also recently had our first CVEs in Gleam, found by researchers using AI. This was very cool an impressive!
I’ve not yet managed to find a way to improve development productivity using AI in my testing and experiments. We recently had some help from AI experts from a large tech company I’m not yet at liberty to name, and their position was that with the current state of the art with the amount of funding etc that Gleam has it’s not really viable for us to get the productivity and quality we hope for.
Thank you!