Published 06 Feb, 2025 by Louis Pilfold
The results are in for the first ever Gleam Developer Survey! It ran for a couple months at the end of 2024 and received 841 responses! Thank you to everyone who took part! š
The survey was a Gleam web application with both the frontend and the backend written in Gleam. It was deployed to a physical Linux server and wrote data to the local filesystem as JSON files rather than using any particular database.
All the questions in the survey were optional, and several of the questions had a free-text field for people to give their answers. For these free-text answers Iāve manually categorised them so that we can see some trends, and the raw data is not shared in order to protect the privacy of the participants.
First weāll go over the numerical data, and after that Iāll outline common trends in the free-text answers.
Whatās your job role?
What country are you from?
Gleam folks are all around the world! London and Paris have active Gleam meet-ups, hopefully other top countries such as Germany and USA will start similar community groups in the near future.
Are you a Gleam user?
The survey was open to everyone with any interest in Gleam, rather than just experienced users. Around three quarters of respondents are using Gleam, which is a great indicator of adoption in the languageās first year.
Are you using Gleam in production?
Around 8% of people of respondents have got Gleam into production, despite the language being less than a year old! Encouraging and enabling production use is one of our primary goals presently, so this result is very satisfying, and I hope the trend continues.
Does your organisation sponsor Gleam? (just production users)
We have had much less success getting sponsorship from corporate users. This is disappointing as everyone benefits from dependencies being well maintained and sufficiently funded. The silver lining is that our lack of success here implies that there is more money on the table, and if we find some other method that works better for corporate users then we may be able to substantially increase project funding.
How large is your organisation
Just production Gleam users
Production users of Gleam are more likely to be in smaller organisations. This likely is due to larger organisations being more risk-averse than smaller ones, and Gleam not yet had time to build a reputation as being a strong and reliable foundation for a technology project.
Where do you get your Gleam news from?
The Gleam Discord server continues to be the place-to-be in the Gleam community. Gleam Weekly and reddit have grown a lot since v1.0.0, providing two good options for folks who do not have the desire or the time to participate in a busy chat server.
How much professional programming experience do you have?
How much Gleam experience do you have?
Some folks have been using Gleam since way before v1.0.0! Thank you for staying with Gleam for so long! I think I can guess who these people are. š
What Gleam compilation targets do you use?
Sometimes people think that Gleamās JavaScript target is an afterthought or somehow less important, but it is used a lot. It is also interesting to see how some folks donāt know what target they are using. I think this shows how the Gleam tooling does a good job of letting you get started without having to learn lots about the surrounding ecosystem, but perhaps we could do better at education in some fashion here.
Just production Gleam users
Among production uses Gleamās JavaScript target is even more widely used, likely for web frontends. Note that these are not distinct groups, many respondents will have picked both.
What runtimes do you use to run your Gleam code?
Predictably the Erlang VM (the BEAM) is the most widely used runtime, but weāve also got a few folks using AtomVM, an alternative Erlang runtime optimised for resource constrained environments. It would be good to have better support for this runtime in the Gleam toolchain.
Just production Gleam users
What operating system do you use in development?
A strong showing from the usual suspects, and good to see some more uncommon operating systems in there too. Windows being so common is a good reminder of the importance of having good Windows support. Itās vital that we donāt leave that huge portion of potential users behind and limit Gleamās growth.
What operating system do you use in production?
The BSDs showing quite strongly here too! It would be great for the Gleam project to be able to run the tests on and provide binaries for FreeBSD and OpenBSD, but unfortunately our CI system, GitHub Actions, does not support them.
Some people put platforms such as āAWS Lambdaā or āKubernetesā as their operating system here. Iāve largely put these within the āLinuxā category.
What sort of projects do you make with Gleam?
Itās wonderful to see so many people making applications! People tend to share or publicise libraries more than applications, so we donāt get to see as many of them as we would like. This year we hope to devise some ways to encourage people to share applications, thereās a lot we can learn from studying them.
Do you use Gleam for open source development?
Itās great to see so many people using Gleam for open-source. Gleam is a community project, so we greatly benefit from people making and sharing via open source.
Do you sponsor Gleam?
Just production Gleam users
Itās great to see so many people sponsoring Gleam! All the funding for the project comes from sponsorship rather than a corporate owner. This gives us more freedom to make Gleam the best language possible, and removes the risk of the project falling victim to changes in business priorities, but means we have less funding overall. Having a good amount of sponsorship is vital and we hope to continue to grow it so all the core team can be paid appropriately.
What other languages do you use?
Wow, what a lot of different languages! A common misconception is that Gleam in some way competes with Erlang and Elixir, and draws programmers from those communities. This is not the case! People who enjoy the dynamic and expressive styles of those languages tend not to gel quite as well as the much stricter and type-directed style of Gleam.
With the answers broken down into Erlang and Elixir vs others this can be seen more easily. Gleam folk overwhelmingly come from other ecosystems, often ones that already use static types.
Free text responses
It took a long time to read all the various messages submitted to the survey. Overwhelmingly everyone was very supportive, and we didnāt have any trolls or similar. Hereās some of the common themes in the messages:
Easier JSON decoding
Gleam is a sound statically typed language, so when data comes in from the outside work it needs to be converted into well typed data before it can be used. This is done using dynamic decoders. The original API for these could be challenging to work with at times, and the survey responses highlighted it as a sore spot in the Gleam developer experience.
Since the survey we have completely redesigned this API, making it much easier to use and also removing some of the limitations people would get stuck on. The language server has also gained a code action to generate decoders for you from type definitions.
OTP actor framework improvements
Gleam is part of the BEAM language, so it makes use of the OTP actor application
framework. One can use the regular Erlang implementation, but there is also a
library called gleam_otp which provides a type safe version of the same
concepts and protocols, while maintaining compatibility.
gleam_otp is somewhat minimal and respondents wanted it to be expanded, which
we intend to do over the next year.
Language server renaming
Gleamās language server provides IDE-like features to all text editors that support the language server protocol, which is most mainstream editors. At the time of the survey it lacked support for the ārenameā feature, so Gleam programmers would have to rename things manually.
We agree this is a missing piece and is highly sought after. Renaming of arguments and local variables has been added recently, and we intend to continue to add more renaming functionality.
Macros and metaprogramming
Several respondents expressed a desire for macros or metaprogramming, though rarely did it include any details of what that might mean or any justification as to why it should be added. Metaprogramming is a lot of fun in many languages, so it is understandable that people would want their favourite type of metaprogramming in Gleam, but we need a more detailed proposal before we can move forward with any language editions, especially one so large in scope. This blog post details what this proposal process needs to look like.
Documentation
People like the current documentation but they want more! I agree, this is very important. Help with making applications and getting them into production was especially highlighted. Documentation and production is one of my main priorities for 2025.
Video content was especially in-demand. I intend to experiment with some video guides for key areas of the Gleam ecosystem.
Compilation to a single binary
This would be a cool feature to have, but we donāt have any particular plans to do this at present. Perhaps one day!
Easier installation of Erlang and rebar3
Installing Gleam is easy, but installing Erlang and rebar3 (Erlangās build tool) can be difficult, especially as they are not distributed together (making version mismatches possible) and Debian and Fedora both currently have Erlang packages which are incomplete and can fail to compile simple Erlang programs.
This is a wider problem in the BEAM ecosystem and we are collectively working on making it easier to install these dependencies.
Libraries
Some people want websocket support in the Wisp web framework and stabilisation of the core libraries, both of which are planned for this year.
The lack of a core time library was highlighted as making it unclear how best to
work with time. This week the official gleam_time library has been published
to resolve this issue.
Some people want a much larger standard library. This is not something we intend to do as we believe a ābatteries includedā standard library is a relic of times before effective package management, and today it is more practical to have a selection of well maintained packages that all work together but can be upgraded or replaced independently than to have one monolithic library where the majority of the code is unused or discouraged.
A convention based backend web framework in the style of Rails, Django, or Phoenix was a not-uncommon request. This is not something the core team has any plans to work on, but perhaps the community will produce such a project!
The end
And thatās all! Once again thank you to everyone who took the time to fill out the survey, it has been a great help. See you next year!