Console #149 - Interview with Louis of Gleam - a language for building type-safe, scalable systems
Console #149 - Interview with Louis of Gleam - a language for building type-safe, scalable systems
Featuring react.dev, Miller, and Gleam
🤝 Sponsor
This space is reserved for sponsors that support us to keep the newsletter going! Want to support Console? Send us a note at osh@codesee.io
🏗️ Projects
Browse through open source projects on OpenSourceHub.io, add your project to get more exposure and connect with other maintainers and contributors!
🌐 react.dev
react.dev is the new home for React and its documentation. It teaches modern React with diagrams, illustrations, challenges, and over 600 new interactive examples.
language: TypeScript stars: 8944 last commit: today
repo: github.com/reactjs/react.dev
site: react.dev
👨💻 Miller
Miller is like awk, sed, cut, join, and sort for name-indexed data such as CSV, TSV, and tabular JSON
language: Go stars: 7349 last commit: 3 days
repo: github.com/johnkerl/miller
site: miller.readthedocs.io
⚡ Gleam
Gleam is a friendly language for building type-safe, scalable systems! It compiles to Erlang (or JavaScript) and has straightforward interop with other BEAM languages such as Erlang, Elixir, and LFE.
language: Rust stars: 4746 last commit: today
repo: github.com/gleam-lang/gleam
site: gleam.run
Join thousands of other open-source enthusiasts and developers in the Open Source Hub Discord server to continue the discussion on the projects in this week's email!
🎙️ Interview With Louis of Gleam - a language for building type-safe, scalable systems
Hey Louis! Thanks for joining us! Let us start with your background.
Hello! I’m a London based long-time lover of the open source software community and programming languages. In my former life, I was very much an audio technology guy, and I got into Linux and the open source world through a fantastic piece of DJ software named xwax. After having a blast using it to pay parties and getting stuck in with the community, I eventually decided I should learn to code, so I could contribute in that way too. I’ve got a little off-track with that music programming adventure, but I’m sure I’ll get back to it one day. 😁
For the last half-decade or so I’ve been working on a delightful programming language called Gleam, which attempts to bring the strengths of various different popular functional programming languages together in one. Most notably, it features the massive concurrency and fault tolerance of BEAM languages like Elixir and Erlang, and the reliability and easy refactoring of ML languages like Elm and OCaml.
In many ways, Gleam is a love letter to a variety of different languages, and I’m really glad that Gleam’s design is really resonating with other people too!
What’s your most controversial programming opinion?
I’m not sure this is very controversial, but I think we think far too much about big problems and big systems when programming! Not everything needs to use a big and complicated enterprise ready framework that can scale to a planet-wide user base of many millions of users.
Many small businesses would do fine with a “boring” monolithic application deployed to two or three servers, or onto a convenient platform like Fly.io or Heroku. Many distributed event brokers and multi-leader databases could be an instance of PostgreSQL or MySQL, or even SQLite3. Many sophisticated services could be a shell script running as a cronjob.
I find there’s a real joy in programming in the small. Identifying an appropriately sized solution to the problem and doing that, saving lots of time, money, and pollution from carbon emissions and electrical waste. So satisfying!
What is your favorite software tool?
I like little things that make your day easier. My most recent favourite closed source tool is TailScale, a SaaS product that makes setting up a peer-to-peer VPN incredibly easy, as well as a few other things.
In the open source world, there’s a tiny perl program called vidir which allows you to open the current directory in your text editor and rename and delete files with all the fancy features you have in your editor. Much nicer than trying to remember the syntax for whatever batch renaming program you’ve got installed.
If I gave you $10 million to invest in one thing right now, where would you put it?
I’d form an organisation dedicated to the development and the stewarding of the Gleam language and its community.
Where did the name for Gleam come from?
Gleam primarily runs on the Erlang virtual machine, which is called the BEAM. The word “gleam” is a synonym of and rhymes with the word “beam”, and it’s easy to spell and say, so I thought it was a good choice.
Are there any overarching goals of Gleam that drive design or implementation? If so, what trade-offs have been made in Gleam as a consequence of these goals?
Gleam is all about productivity and making working on software as fun and low-stress as possible, and all the decisions about the language are driven from these goals.
Gleam runs on the Erlang virtual machine, so we can have the excellent performance and all the reliability and fault tolerance features the runtime boasts.
Gleam has excellent interop so we can take advantage of the large ecosystem of code written in Elixir and Erlang.
The language features powerful static analysis and a robust type system so that the compiler can identify problems with code that would otherwise require the programmer to debug themselves.
The language is designed to be as small and consistent as possible so that it can be learnt easily and to reduce the cognitive load when reading and writing Gleam code.
The other side of this is that we have to think a lot also about what shouldn’t go in the language. People commonly ask for features from other languages, but often to add them we’d have to sacrifice some of the other properties of the language. For example, type classes would hurt performance, degrade our interop with other languages, slow compilation, and increase the complexity of the language, making it more challenging to learn and read. These features may be excellent in other languages, but they may not be the right fit for Gleam.
There’s an interplay between all aspects of a language, so adding or changing a seemingly unrelated feature can have knock-on consequences for other features. Changes have to be very carefully considered.
Is Gleam monetized? If yes, what is your main source of revenue?
Gleam is funded entirely by a collection of wonderful people through GitHub Sponsors. I feel very strongly that the project must remain an independent community project and outside the control of any one company. A company has its own motivations, and while they may align with Gleam’s at the start, there is no guarantee that they will do in the future. Too many open source projects have suddenly halted or otherwise been in trouble due to a change in business priorities.
In future, I’d like to have relationships directly with companies that wish to more significantly sponsor or otherwise support Gleam outside of GitHub Sponsors. The details there we’ll figure out once those companies present themselves.
How do you balance your work on open-source with your day job and other responsibilities?
Historically, I’ve balanced them by doing a heck of a lot of hours. It’s really challenging to run such a large project around a full time job, and burnout is a constant risk. I’ve multiple times in the past quit my job to lower the pressure and just worked on Gleam full time until I ran out of savings, and had to get another job.
These days I work full time on Gleam, and if all goes to plan that’ll be my job indefinitely. Financing the project is a challenge, but thanks to Gleam’s sponsors I now earn enough to pay my bills, which is a huge relief.
The software industry has a huge problem in supporting open source maintainers and projects. The relationships are very one-sided. Companies take tremendous amounts of value from open source projects, but very rarely contribute anything back.
If every company that used open source software took a tiny portion of their product budget and gave it to the projects, it would benefit everyone. Open source projects would be healthier, better maintained, and higher quality, and the companies would directly benefit from those improvements.
Have you ever experienced burnout? How did you deal with it?
A previous workplace of mine underwent a hostile takeover from our main competitor, and went from being a wonderful place to being a very stressful and frustrating experience. Most of the product department left in a few months and I burnt out trying to hold everything together, both technically and personally, for the remaining team members.
In the end, I had to quit and take a break from working in a company to recover. Luckily I wasn’t so far gone that I couldn’t work on things, so I took this time to experiment with bootstrapping a start-up, and towards the end of this period I also started working on Gleam more seriously.
What is the best way for a new developer to contribute to Gleam?
The best way to contribute is to do whatever it is that you enjoy with Gleam! That could be making libraries, working on the compiler, writing blog posts, doing Gleam streams, or just hanging out in the Discord server. Just being a member of the community and spreading the Gleam excitement is excellent in itself.
Are there any other projects besides Gleam that you’re working on?
Nope! It’s all Gleam, all the time!
Having said that, Gleam is really a multitude of projects, so I get to work on lots of different things. Lately I’ve been working on the compiler, the language server (an engine that brings Gleam IDE features to all editors),
Where do you see open-source heading next?
I really hope it’s going to involve more financial support for open source maintainers. As lovely as it is to get basic free access to various SaaS products and a free Hacktoberfest t-shirt, what we really need is regular income to pass our bills with!
Want to join the conversation about one of the projects featured this week? Drop a comment, or see what others are saying!
Interested in sponsoring the newsletter or know of any cool projects or interesting developers you want us to interview? Reach out at osh@codesee.io or mention us @ConsoleWeekly!