Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Is Gleam your next programming language?
1.6k Plays1 year ago
Louis Pilfold joins us to talk about Gleam, a new language that runs on Erlang's BEAM. In creating Gleam, Louis has tried to bring a new level of developer-friendliness to Erlang's famously fault-tolerant platform.
If you're interested in building reliable distributed systems, exploring functional programming, learning new languages or finding out what it takes to design your own language, Louis is here to talk us through it all.
The Gleam language: https://gleam.run/
Gleam’s package repo: https://packages.gleam.run/
Gleam on Twitter: https://twitter.com/gleamlang
Kris on Twitter: https://twitter.com/krisajenkins
Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
Recommended
Transcript
The Need for New Programming Languages
00:00:00
Speaker
Why are there so many programming languages? And given that there are so many, how come people are still creating more of them? I mean, it's a lot of work, right? It's a heck of a lot of work to do something we seem to have plenty of. Why bother?
00:00:17
Speaker
I think there are a few really compelling reasons. Some people do it for research. They have an idea of how programming could look in the future, how it could be, and they want to take that idea for a walk, put it through its paces, explore it further.
00:00:32
Speaker
Other people create a new language because they're cherry picking. They look out into the world and say, well, I like Python's programming model, but I want C syntax and some of Go's concurrency features. So I'm going to put them together in something new, a bit like a recipe making. They're baking their own cake. And other people build a language because there's a hole in the market. JavaScript is the famous example. It exists because browsers needed a programming language. So someone had to create one.
00:01:03
Speaker
And that's actually my favourite thing about JavaScript. It took you to somewhere you couldn't have gone without it.
00:01:09
Speaker
But all these motivations come together in the creation of a relatively new programming language called Gleam. You might not have heard of Gleam, but stick around because you're about
The Birth of Gleam Language
00:01:19
Speaker
to. I'll give you one metric. If GitHub stars are anything to measure by, it is apparently more popular than F sharp. So let's find out why. I'm joined today by the very charming Louis Pilfold, who's the creator of the Gleam programming language. And he's going to tell us why he thought the world needed a new language.
00:01:38
Speaker
How he survived for the multi-year crazy journey it takes to go from idea to production. And what Gleam has to offer us as programmers. We're all out there trying to get a job done. Can Gleam help us do it better? Faster? Easier? Cheaper? More fun? Any of those? Some of the above?
00:02:00
Speaker
Well, let's find out. Let's get cracking. I'm your host, Chris Jenkins. This is Developer Voices. And today's voice is Louis Pilfold.
00:02:22
Speaker
I'm joined today by Louis Pilfold. Louis, how are you doing, man? I'm great. Thanks for having me. Good to see you. Oh, it's a pleasure. Yeah, it's good to see you. We haven't met in person since before the pandemic. Oh, since before the event. Yes. The event that shall not be named. Yeah, I keep having to bump into you, but yeah, just digital do for now.
00:02:43
Speaker
They'll have to, even though London's not that large, but now I do it online. I feel like with the same city and similar interests, we would have bumped into each other at a tech or something with lots of people making bloops and bloops with synthesizers and stuff, but no, nothing yet. Yeah, yeah, yeah. Sooner or later, we'll cross paths again. But for now, I have been keeping tabs on you in my secret tracking cave. Ominous. You've been busy writing a whole programming language. I have.
00:03:09
Speaker
Yeah so started as a pet project and grew wildly out of control and is now dangerously useful it's quite nice. That's something i want to get into but first we should probably set the frame and what is your language is called gleam right yes.
00:03:25
Speaker
What is it? Why do we need a new language? Well, so I think it really comes from me being always a little bit, so I'm a person who loves languages, which I think you are as well. So I always try and, you always used to try and learn a new one or two or three like every year or so. And I reached this point where I was just annoyed with every language. Because when I was writing, when I was writing Elm, I wished I was writing Haskell. When I was writing Haskell, I wish I was writing Erlang. When I was writing Erlang, I wish I was writing Rust. You know, it's like, I wish I had.
00:03:55
Speaker
that bit from there and that bit from there. This would be really easy if I had that.
Gleam's Design and Erlang Beam Integration
00:03:59
Speaker
And so, yeah, I ended up sort of like saying, well, what happens if I try to like draw all of the best bits? Could I make something that was like cohesive and really nice? Or would it just be, you know, the horrible mash of bells and whistles and nothing quite fitting together? See, I know a few languages that have asked that question and their answer has been a horrible match. Yeah.
00:04:23
Speaker
How are you feeling about your answer? Good. I think it's tricky. I took a lot of inspiration from Lua and Go. As a functional program, I don't have to put you off. I don't mean it's a very simple procedural language, but I try to make the surface area of the language very small and try to make it very consistent, hopefully more so than Go, I think.
00:04:47
Speaker
And yeah, it's just sort of like, what are the really valuable things from these different types of languages, which I think are really interesting? And then how can we take the smallest amount of all of them and make it as possible? Which I think is not the way a lot of people go for languages. It seems to be like adding more, but I'm trying to like have
00:05:06
Speaker
Less. And yeah, a bunch of years in, it seems like it's really resonating with a lot of people. So that's quite nice. I'm pretty happy with that. Very cool. OK, so tell us what you've picked from the buffet car of languages. So it is a simple functional language, sort of in the style of Elm, perhaps. I think you're an Elm fan from the past. I'm an Elm fan, yeah.
00:05:35
Speaker
The language got quite a small number of features and we generally say like, well, you've got functions and they take in values and they return values and you kind of ignore everything else. That's sort of all you need. But rather than having like an Elm syntax, although we did originally have a syntax like that, we've got a syntax that's much more familiar to, you know, JavaScript programmers or C programmers, you know, lots of curly braces and all that stuff.
00:05:57
Speaker
And I originally thought, oh, what's the point of that? You know, just syntax doesn't matter. And then we switched syntax and suddenly everyone was like, oh, this language is great now. I was like, nothing's changed.
00:06:06
Speaker
So I was wrong, syntax really does matter. And I sort of miss the old one, but the new one people really like. And the thing that is, I think, one of the big sales bit is that it runs on the Erlang virtual machine, which is called the Beam, which is unusual for a virtual machine that is designed for functional languages from the get-go. And rather than being like a research project, like a lot of functional things are,
00:06:33
Speaker
it was built for industry, it was built for telephone switches, Ericsson, so it's got loads, it's really built with running and maintaining and debugging really reliable systems.
00:06:48
Speaker
That's interesting. So, the main thing I know about the beam, other than it's not Apache beam, it's Erlang beam, is it's famed for its novel approach to reliability. Yes, yes. So, like, we're trying to both think lean, you know, there's all these arguments between the typing people and the Erlang people about how do you should deal with errors, like, oh, you should make it impossible in the Elm world, you know, make
00:07:12
Speaker
making valid states unrepresentable in your program, which is actually really fantastic to do that. But all the early people are like, no, that's rubbish. Because how do you make memory corruption impossible in your application? What if you've got a cluster of computers and want to get struck by bolt of lining because it's up a telephone pole doing run a telephone switch firmware?
00:07:34
Speaker
you can't really do that with types can use the whole thing is about failure is gonna happen. You just have to lean into that your entire system needs to be able to explode in some dramatic way and you should be able to survive that and it sort of boils down to the sort of.
00:07:50
Speaker
IT crowd, have you tried turning it off and on type thing? And breaking your system into loads of tiny little bulkheads where like, oh, when everyone's gone wrong in this subsystem, okay, let's restart that. Did that fix it? No? Okay, well, let's go one step bigger. What if we discard the corrupted state in that system and then just like slowly, incrementally drop things out? So you can kind of see parallels between the beam and maybe Kubernetes or something.
00:08:18
Speaker
So if you've got a pod, a deployment of a web service that's raining out or something, and something goes wrong in it, the instance goes down, and then Kubernetes brings it back up again, and then it should be a good state. And you've lost those jobs that are in progress, but then it should be okay.
00:08:38
Speaker
That's really cool, but kind of rubbish in that that single instance of a Go program is probably running hundreds or maybe thousands of jobs at the same time. So losing the whole thing sucks. So imagine if you could have that whole pattern, but rather than at a sort of data center level, you could have inside your program level where your single VM instance is really running hundreds, thousands, millions of threads, and you can do that incremental state shedding at the individual thread level.
00:09:08
Speaker
So maybe you just lose like one web request. Yeah. Yeah. The idea is, I mean, you can sort of do this sort of things like, you know, try catching in, you know, other languages, but it's, it's a lot much more, it's taking the idea of like, you know, we'll catch it and we deal with it, but in a much more, um, in a much more fine grained and sort of sophisticated way than you would do in other languages. And it just results in.
00:09:32
Speaker
Yeah, it results in extremely reliable services. There's companies that claim nine nines of reliability with Erlang, which I'm not sure I've ever seen proof of that. But the fact that they can claim it and people go, oh, maybe. I think that says a lot about how good this thing is. And it also means you can do things on the radar to look at, right? Yeah, exactly. The fact that it's plausible implies that, yeah, this is really...
00:09:55
Speaker
extremely good. And it means you can do things like offensive programming quite happily. I'm just never going to check any of the errors. I'm just going to insist that everything succeeds. And if it fails, well, I don't need to write any error handling logic in my business logic. That can be dealt with out there in the ether with non-local error handling, as they might call it.
00:10:17
Speaker
I've always wondered, does that just result in systems that are constantly trying and crashing and trying and crashing in an infinite loop of let it crash? Yes. Sort of. There's a company called, oh, I don't know how to pronounce their name. That's embarrassing. They're the people who run PureScript on the Erlang virtual machine.
00:10:38
Speaker
and they do video streaming and they said they had a bug where the system would crash every 100 frames or something like that and they didn't notice for eight months because it just ran so well like they didn't notice any problems in the area it would just it would run for 100 frames crash system would restart that tiny little subsystem and then it would continue
00:11:04
Speaker
Oh, so it was picking up after every hundredth frame and they got this. It's like, oh, we'll just retry that frame. They just didn't know. And I was like, maybe they should improve that, you know, monitoring, but the fact that you can, the fact that, you know, so if we think about running systems in production, um, we want to,
Accessibility and Community in Gleam
00:11:20
Speaker
we want it to continue working for our users, but you also were not to want to have a really stressful time when it does go wrong.
00:11:26
Speaker
So when things do start crashing, you do want to know about it. And there's lots of mechanisms for that. And you do want to be able to debug it. There's lots of mechanisms for that. But mainly, you don't want to be woken up at 3 in the morning with people screaming down the phone saying, you've got to fix it. You've got to fix it. You want to be able to do it in the most low-stress way possible, right? So it's all about holding itself together just well enough for you to deal with whatever the problem is.
00:11:54
Speaker
Right. Because that kind of monitoring, debugging and failure handling baked in from the start in industry, I think really appeals. Yeah. And I've often like, for the sake of the platform, the beam, I have gone towards Erlang for a look and Erlang's really weird. Yeah. And I say that as a lisp Haskell programmer.
00:12:20
Speaker
Erlang is weird, right? And it's put me off every time. Yeah, I think that's part of the problem. The Erlang runtime has got these amazing properties because they come from real world requirements. We want to make sure that a greedy green thread can never block the scheduler and cause any problems or anything else. So you can have a hot loop and it just
00:12:43
Speaker
everything continues running, that's fine. If someone says there's a bad regex, we don't want it to block the scheduler. If something crashes, we don't want it to bring down the system, all these things. They've got that all down, amazing. But the actual language
00:12:56
Speaker
I mean, I love it. I'm just gonna say first looks dreadful. It looks so bad. And it's like, it's really awkward in lots of ways. And the tooling is strange. I was looking, I was refreshing myself earlier. And I had a look. And I'd forgotten about this. But to export a function out of a module, you have to export function name slash the number of arguments because of my start slash one. Yeah, because function functions are
00:13:26
Speaker
they're not just a unique name, it's like unique based on not just the name, but also the number of arguments. So you could have like, main zero, main one, main two, main three, there's all separate functions. It feels like something a computer could take care of for us. Yeah, but if you it's true, and we do do that. But like, well, he's gleam does do that. But
00:13:50
Speaker
If you have that control, you can actually do different things. It's actually more powerful. You can actually decide if you want to reference the one or two or three. I don't know. You just end up with, in Erlang, they do use it a lot. It's these sort of things like whatever tools you're given and you're used to, you will find uses for.
00:14:11
Speaker
And so even though I, as a person who likes, you know, Rust and Elm and things like that, I'm looking and going, I'm not sure I like that feature very much. All the Erlang and Elixir people complain constantly that they don't have this when they're trying Gleam. So you're sort of damned either way really. And with, you know, one of the goals of Gleam is to make all these wonderful things you get in the Erlang world
00:14:38
Speaker
make the much less alien seeming to the rest of us. There's only so much strangeness you can tolerate. If someone is mildly interested in Erlang, because they've heard these really cool things about this super concurrent fault tolerant runtime, and they're suddenly met with Erlang, they might go, this is just weird. This is too much. The weirdness is greater than my curiosity. I'm going to go somewhere else.
00:15:04
Speaker
So I want something that looks a lot more normal, you know, and even if that is worse in some ways, if we can get more people that'd be better. That'd be better enough always, you know, it's always a trade-off.
00:15:14
Speaker
Yeah, yeah. Let's use the word accessibility because that makes it sound really good. Okay, not weirdness. Accessibility. Not weirdness. Yeah. I did once ask the creator of, it was after a conference and I had a couple beers so I was feeling a bit brave and I asked the creator of Erlang, why does it look like that? And he said, oh, you should have seen it before we open sourced it. It looked much worse.
00:15:40
Speaker
Awesome. I can only imagine. Go Armstrong, right? I was asking Verding, but yes. Oh, OK. So did you explicitly, when you're going around picking up your favourite bits of languages, was it always the case that you wanted to compete with, replace, offer an alternative to Erlang, but be on the beam?
00:16:04
Speaker
I've been a Beam user for a long time. I got it through Elixir and I quite quickly ended up writing early as well. I quite enjoyed both languages. And it being a runtime that isn't used very much and I love a lot, it just seemed like quite an obvious choice to use. Even before I started thinking about like, how could this be useful to people? It's like, I really like this runtime. I really want to use it in my ideal pet programming language that no one's ever going to use.
00:16:31
Speaker
They seem like the right way to go. But even if I was designing it to be like, this is for people, which I do now, but from the very beginning, I think I would have made the same decision. But I don't see it being competing so much because I think the people who are going to come to Erlang and the people who are going to come to Gleam are two different sets of people.
00:16:53
Speaker
Um, there's lots of people who, you know, there's lots of people who have any interest in the runtime, but we'll say this thing has like a weird prologue mishmash syntax and it is dynamically typed and it has loads of sort of unusual.
00:17:08
Speaker
not quite prologue, not quite this, not quite that, patterns and stuff in it. That's probably not for me. I'll go write Scala or something else. And there's lots of people who are always got this weird Ruby syntax. I'm not sure about this Elixir thing. It's all weird Lisp macros. That's not me. I won't use it either. Well, the people who don't like those two things may like the idea of a C-looking, small, functional language that has a sort of an Elm-style type system.
00:17:37
Speaker
So I don't think we're going to draw so many people from the Erlang and Elixir world. I think it's going to be much more we're going to bring people to the Beam community as a whole, really. So I'm hoping we'll work together. And a lot of Gleam as a language is built around the idea of interrupt between Gleam and the other languages as well. So hopefully people can write things in Erlang and Elixir and we can use them, but hopefully it's also the way around. We make it really easy to write things in Gleam and then that will be able to be used by the Erlang and Elixir folks as well.
00:18:06
Speaker
Okay, so that's often overlooked, that kind of two-way interop. Yes. You can be both, you can both consume and provide. Yeah, the tooling's a bit, isn't quite as good there as I would like it to be, because it depends upon the Erlang and Elixir people building a bit of tooling, but there are ways that they can do it. Yeah, I think there's like, you know, there's loads of value in it, because we're not, I don't want to compete with Erlang and Elixir, because I'll lose.
00:18:33
Speaker
And also, why would I want to compete with my closest neighbors? I want to be working together. And I wish more languages thought about it. Erlang means the universal language of the platform. It's quite easy to work in both directions. But Elixir is very much designed to be able to use Erlang code. But it's trickier in a lot of ways to use it from Erlang. And there are certain features you just can't use.
00:18:57
Speaker
That's just the trade-off they've made. Fair enough. Well, an interrupt future, if we'll get there, eventually. Universal computing. But take me through the... So, I... And I know a few programmers who've done this have written like a hobby programming language. It's kind of one of those rites of passage once you've been programming for long enough.
00:19:18
Speaker
And I realized two things from doing that. The first is that a programming language isn't magic, right? Writing a program that evaluates source code is actually really interesting and not that hard. But the journey from that hobby project to something you can actually put in production is huge. Take me through your journey on that. I think it's just stubbornness on my part, really.
00:19:46
Speaker
I sort of explain these people who don't understand tech as being a chap who's built a model railway in his garage. It's like a very, very large ornate one with multiple layers and realistic representation of talent. You look at it and you go, why have you done this? It's very impressive, but that was clearly a lot of time.
00:20:09
Speaker
But yeah, it was just curiosity because I love languages and there's just so many bits you can dig into. And so that kept me interested and busy for a few years, maybe the first two or so. But I was quite lucky in that I was already fairly well known in the Erlang and Elixir world because I got onto Elixir quite early.
00:20:31
Speaker
And I'd done a thing of, oh, well, Alexa doesn't have this thing that I used to use in Ruby or Elm or something. I really wish I had that. Maybe I'll try and make one. So I made a linter.
00:20:45
Speaker
which was forked and is now the main linter in the electric system, which is great because I don't have to maintain it. And I wrote... Build it, open source it, push it out the door. Exactly. It's much better than the one I wrote, but it was mine originally.
00:21:04
Speaker
And I wrote a formatter, because I thought Elm format was amazing. And so that then inspired an official one. So just from these things, I was sort of known a little bit. And then when I started doing this language thing, and I put lots of fashionable words on it, like types, people are like, oh, that's interesting. And it's sort of like people started chatting a bit, because I'm always insistent on developing in the open. So even though I wasn't really publicizing it, people would look at it and say, oh, look at this thing here. And then that gave me a lot more
00:21:35
Speaker
Well, when people show interest in your work, you know, it gives you a lot more, it gives you encouragement, you know, you want to keep working on it. And then I slowly got this idea like, maybe this, maybe this, I actually quite like all the ideas I've come to here after, you know, a couple years of work on it. Maybe this could be useful for something.
00:21:52
Speaker
And now we're in a place where people are using it, which is why. That's amazing. There are a large number of pieces you must have put together along the way, though, because just adding a type system to a platform that's never had a typed language, that's a whole chunk of knowledge and research.
Gleam's Development and Tooling
00:22:10
Speaker
Yeah, that was quite painful. I knew I was always a lover of well-typed languages, but never knew how they worked. I think part of the reason why Gleam is doing well is that I'm not a
00:22:28
Speaker
I'm not a very academic person when it comes to like the theory of the implementing these things. I would describe myself more as like a language designer than I am a language compiler implementer or a runtime implementer, which is a shame because I think there's really fascinating things, but all my learning has been I want specifically X. I've
00:22:51
Speaker
Spent a lot of time experimenting with different language designs, like, what if the language had this feature? And then I would write loads of code as if it had that feature, and then just compile it in my head, and go, what would that do? How would that work? How could I write these programs? And I'd go through that loop over and over again, and go, right, I want this. Now, how does that? I know people can do this. How do I do it? And I'd have to find the suitable amounts of understandable papers and stuff to try and work out. And it was just, it was misery.
00:23:20
Speaker
I sort of know a bit about some type systems now, so that's good, like enough to make a useful one. Could you pass the exam there? I'm sure I couldn't.
00:23:32
Speaker
It's not loaded into short-term memory. I'm very good at anything that Gleam has inside it, and anything it doesn't, I don't know. It's frustrating a bit because you get to a point where you understand it well enough, and that's because you've successfully implemented whatever that feature is, and I'd really like to continue learning it, but I actually need to do this other unrelated thing for the language.
00:23:55
Speaker
One thing Gleam does, which I think is quite clever, and I think more languages should do, is that all the bits that you commonly touch are considered part of the core language, not the core language, but the core project. So we don't just have a language and a compiler.
00:24:12
Speaker
We've also got a build tool and package manager and language server and all these sorts of things and a package index. So rather than leaving those things up to the community, that'll be baked in. And that's resulting in a really good experience. But it just means I've learned something interesting about type systems, and I have to go work on dependency resolution algorithms instead. And I never actually get good at any of them.
00:24:38
Speaker
How on earth do you stay on top of all of that? Because each one of those could be a project in itself, right? It's building a package manager from scratch and making it good. There are teams of people that do that. Yeah. So with package management, we can... Luckily, we're forced to cheat a little bit and we want to interrupt really well with the rest of the Beam language, so we use their package manager. So the side of...
00:25:05
Speaker
you know, uploading and distributing, well, all the server side stuff, somebody's already built that, we just have to use their API. A bit confusing because no one's really, I think, as far as I can tell, two people have integrated ever with that API, so the docs are not amazing. Three now. So by the time I worked out that, yeah, I only need to do the client side, but that's still really complicated, like the algorithms for how you
00:25:31
Speaker
Work out which version she's a bunch of a bunch of constraints is quite challenging. A lot of it is just working out what is the it's the whole start up thing right now what is the MVP of each things what is the smallest useful approach and.
00:25:51
Speaker
Having a language that is designed to be small, because I think that is a better experience as a user actually makes it a lot easier to implement as well. If I was trying to make a rust or a Scala, it would never be possible with it, but I'm trying to make it a lure or a go. Right. Yeah. Oh, I can hear your cat in the background. Happy little guy. So.
00:26:17
Speaker
Do you think because I've followed a bit about your design process and you say you're doing like fantasy programming design. I also know you've done things like gone off to Twitter and said, hey, what syntax would you expect for this behavior and stuff? And you've run regular Twitter polls on design and you're keeping the language small and that allows you to make certain design choices. What's
00:26:42
Speaker
It's been important about making a cohesive language. Some languages do that well, some do it badly. How do you approach that? All the polls and stuff are really useful.
00:26:56
Speaker
You know, I want to make things not, what's the word we said? Accessible, not weird. Yeah. And I just find that, um, I'm often wrong just about what is normal and what isn't, you know, I think it's easy to assume that your opinion is the, is the standard one, but I just isn't, I've got,
00:27:16
Speaker
So it's really useful to just have it again, sort of sense check and say like, which of these two things looks, you know, try not to ask it directly, like which two things looks least weird, but like sort of ask them simple questions about some example code and just see which ones people get confused by. Because yeah, even if I think something else is a better idea, I'm probably wrong.
00:27:37
Speaker
But it's quite tricky. I think just doing things really slowly really helps. I think that's another reason why having something that's small where I'm doing the majority of the work really helps because I get to spend an awful lot of time. I'll be working on a package manager or something and I will have had an idea for something six months before I even started that, but I'm still working on this for six months. I've got like a year of like, I'm having breakfast staring at the window. I'm like, what if it did this thing?
00:28:07
Speaker
How would that impact this thing? Sort of like gently brewing ideas in the back of your head. And after like 12 months of thinking about these things, you'll have enough moments where something went, oh, but that would interact with this thing. Oh, that's interesting. What about that? And you normally end up sort of accidentally covering all of it just by...
00:28:23
Speaker
Well, I guess obsessively thinking about it for an extreme amount of time. Slow, slow programming. That's my. Slow but obsessive. Yeah. Never stop thinking, but spend a long time. Yeah. Yeah. Cause I know I'm going to try not to name names, but there are some languages that look like.
00:28:40
Speaker
the author has woken up in the morning with a new feature idea, thrown it together as fast as possible and shipped out of the door. And then there are some that feel more cohesive, right? Yeah. And I want to do that. It feels great to have an idea, throw it together and ship it. I dream of finishing Gleam, handing it over to some Gleam foundation that can do things. And then I can just make the language that's all the bad ideas that I didn't do along the way.
00:29:08
Speaker
Because they're always like, the really, the medium bad ideas are where they're bad and you go, yeah, that's not clever, let's not do that. But the really bad ideas are the ones where you go, ooh, that sounds really good, let's do that. And then you think. I don't know, I'm not sure. It's always like whatever sounds fancy as possible. One that is dangerously good sounding is algebraic effects.
00:29:36
Speaker
you can do all sorts of exciting things with that. You can model, you can in-user-land model things like async-await and exceptions and tri-catch and all that sort of stuff. It's clearly a really powerful thing and I think a lot of future languages will probably have it in some degree and it would just become normal.
00:29:55
Speaker
And that's part of why it's such a dangerous idea, because it goes, that sounds great. But actually, would that align with any of the goals of the project whatsoever? I'm trying to make a really simple language that's really approachable, and I'm going to be wedging in a very powerful tool, which is sort of experimental in a few very complicated languages.
00:30:19
Speaker
And it would completely destroy interop with, you know, interrupting the other direction with a lion elixir and stuff like that. So, yeah, it's just not, it's not particularly smart, I don't think. Yeah, I can see why you want to leave it on the table, but still be hankering to revisit it at some point. I really want it. It's just so cool.
00:30:40
Speaker
Okay then, so if you've left that on the table, it does seem like a sensible choice. Which bits have you taken that, if I want to get started learning Gleam, what do you think are the bits I need to know?
00:30:54
Speaker
This is something I'm thinking about at the moment because I'm trying to make a course for learning lean. I've got some funding from the Erlang Ecosystem Foundation, which is a lovely org to try and grow the community in general to make a syllabus on exorcism, if you've come across that, which is a platform for practicing and learning different languages.
00:31:20
Speaker
So in February, we launched a regular track on Xism, which they featured, which is really lovely of them, which is basically like, here's a small programming challenge, solve it, and then you can get, you know, you can have a bunch of tests automatically run for you, but then also you can be mentored by, you know, a member of the community. And it's just a really fab little, really fab site, really recommend using it if you want to
00:31:47
Speaker
practice any languages but they also have another layer on top of that which is a syllabus. So as well as having challenges, they have special challenges which teach you individual concepts of a language.
00:31:58
Speaker
So if you've got a well-made syllabus, you can go from being a programmer, you need to know a bit of programming, and you should be able to go from zero to usable of a language by going through the course, which is really exciting.
Concurrency Models and The Actor Model
00:32:12
Speaker
So what do you need to know? Not much, really. We tried to boil it down. Again, I'm playing on easy mode because it's such a small language, but it's mostly just functions and values and pattern matching and records and all that sort of jazz.
00:32:28
Speaker
okay okay so but i'm gonna need to mix that into some knowledge i mean erlang is very heavily actor-based is gleam like deep knee-deep in the actor model no i so in i think i think
00:32:46
Speaker
It's always tricky with talking about OTP, the Active Framework of Erlang, because Erlang is also quite a small language. It's odd, but it's quite a small language. So when you learn Erlang, you've spent this much time learning Erlang and this much time learning the Active Framework.
00:33:03
Speaker
because it's much more than just like async await in, or, you know, it's much more than like a little concurrency module in other languages. It's, in many ways, much more akin to an operating system, you know, all these like independent things and ways that they talk to each other and patterns you should use so they can look after each other and deal with failure and all this sort of stuff.
00:33:25
Speaker
It's really quite complicated and I think if you go into being programming through airline, you'll probably be spending a lot of time looking at that stuff just because that's quite the forefront of the of that community. However, if you learn if you learn being programming through elixir.
00:33:42
Speaker
they've got much more of a spin on normal sorts of business programming. So, you know, making web apps and websites and this sort of jazz and managing databases. And even though your code is all running inside this active framework, you may never actually see, like I think, I think maybe
00:34:01
Speaker
I've mostly got no data, but I think maybe the majority of Alexa programmers don't write any OTP code at all because they just use, well, I'm using the web server that comes with the popular web framework, and it has loads of actors under the hood, and their PubSub systems are actors, and all these other things are actors, but I just write the web handle a bit that talks with database connection that it's all actors again, and you just don't worry about it. It looks very much like if you're writing an application in
00:34:27
Speaker
Well, even perhaps like Ruby on Rails or Python or something, because there's not even any async await inside the code because it's all just like outside of it wrapping your handler stuff.
00:34:38
Speaker
Right. So, because I've always had the impression that you have to get into that model to get anywhere with Erlang. No. But I could opt into that later once I've got my feet under the table. Yeah, and you may never get there. So the nice thing about the actor model over like, a sink a weight or call backs from futures and things like that, is that
00:35:02
Speaker
If each actor only performs one piece of work, so it's entirely single threaded.
00:35:09
Speaker
You just write code that says, well, I pull the body off of the request object. There's no async. You just block the thread. And then, oh, and then I'm going to talk to the database. No async, block the thread. And then I'm going to send the response. No async, block the thread. It looks like it should be really inefficient, naive code that causes the whole operating system thread to be blocked. But it doesn't, because you're just blocking this one actor.
00:35:38
Speaker
hundreds of thousands of them, quite happily.
00:35:41
Speaker
And people routinely do, right? It's a very normal thing in the Beam scheduler, right? Yeah, yeah. It's super normal. You should be doing that. So Joe Armstrong would say, it's really hard to make one web server that can handle a million requests concurrently, but it's really easy to make one web server that can run one request and then run a million of them. And that's kind of the whole idea of
00:36:08
Speaker
like the early act of things like just do the thing that's really simple for your little whatever the smallest task is and you multiplex it in a completely different place and also something goes wrong you don't get well how do i discard that one bit of states and then not impact with the other ones you go well it's just this tiny little box like off it goes everything else is okay.
Funding and Future of Gleam
00:36:29
Speaker
This is something I love in programming when we have a different way of looking at the same problem that gives really interesting different results. I'm going to have to find time to play with Gleam. Yes. So there are two other things I really want to ask you and maybe we should talk about keeping the lights on first.
00:36:47
Speaker
Okay, because you've, you've done a mixture of things to keep developing this, including being poor, right? Yes. What's it like being an independent language designer? So traditionally, the experience has been
00:37:04
Speaker
I work a job for a while, and I get progressively more irritated with a job, not because the job's bad, although I have had some of those, but just because I wanted to be doing this other thing, and I'm spending my evenings and weekends doing it, and then suddenly I'm going to quit, and I'm going to work full-time on Gleam, and then I just watch my bank balance do this, and then at some point I go, oh, so I need, you know, rents this much, and my bank balance is this much, I should probably get a job in the next 30 days.
00:37:33
Speaker
So I did that like, I don't know, two or three times. But then at some point, GitHub released the GitHub sponsors program, which is like, you know, Patreon for programmers. And some people are like, you should sign up to that. And I thought, you know, the idea that this would ever be a project that could sustain me, I just never even considered it really, because that just making money from open source seems completely impossible, as far as I can tell, unless you've got something very complicated to sell on top of it.
00:38:03
Speaker
So I signed up and then, to my surprise, a few people started sponsoring me. And I was like, wow, that's amazing. I didn't realize I had that level of support. And I just started marketing a little more, focusing a bit more on trying to write
00:38:24
Speaker
Things are actually just good, like let's write more blog posts about how Gleam works and what's going on in the Gleam world so people keep track of what's going on. And then it just steadily grew, and it grew to a point at which, yeah, it's a lot smaller of an income than any other job I've had in a long time. However, it is actually enough to pay the bills. And yes, I'm going, how much money am I willing to sacrifice in order to, A, make Gleam successful and make it exist, but also not have a boss?
00:38:54
Speaker
Well done, something I care about. And yeah, that's a good trade. So now I have less money but can make this thing happen, which is really good. And then that's always looking for little bits on the side to waste money. So if I can find a piece of work that aligns with Gleam,
00:39:15
Speaker
but also can bring some money to you know help make it a bit more sustainable then that's worth doing like applying for grants and stuff like the early as in the early ecosystem foundation one which i mentioned earlier for making this course to learn gleam like that that's a good example for that sort of thing i'd love to do more stuff like that ah cool can i ask i mean feel free to refuse to answer this question because it's about money but
00:39:39
Speaker
The whole GitHub sponsorship thing, is it like, if you've got a few large sponsors, is it lots of little people? What are the rough numbers in there? It's almost entirely money.
00:39:54
Speaker
The biggest one is Fly, the deployment platform. It's also a really good product. I don't have to say that, but it's good. You should probably use it. Fly to IO, right? Yeah, I know that one because they've got good developer experience, but they just do clever stuff for firecracker VMs. And I'm like, oh, that's really clever. I like that. So they give about maybe a third?
00:40:20
Speaker
Maybe a bit more than a third. And then the rest is people who could be giving anywhere between $1, $5, $10, and then a few people give $100, which is just amazing for people. I mean, my ideal situation would be that
00:40:39
Speaker
In the future, the companies that are using Gleam, they'll all give an amount of money that is almost insignificant to a business to not just Gleam, but their dependencies in general. I think companies should give a small amount of money to support any open source projects they use.
00:41:01
Speaker
much less scary for me if I've got like, you know, tens of businesses giving us all that money rather than rely mostly on one company giving a large amount. Because the fly guys have been fantastic. And, you know, I do hope that they continue to support. I'm extremely grateful. But like, there's no reason why they have to, you know, it may, and point may come in the future, they decide that they want to do something else. And that that's that'll be uncomfortable for me. So
00:41:27
Speaker
Yeah, yeah. Did you ever consider, were you ever offered, like, I know the inventor of Elm ended up working for a company that used Elm heavily, and he was just employed to be their in-house language developer. Is that something you'd be interested in? I had a few organizations sort of, we didn't get very far down the process, I think, because I didn't sound very positive towards it, but a few people sort of like gently approached that. But
00:41:54
Speaker
I'm very concerned that having a single company have such a large investment or like a large perceived control in the language will really
00:42:06
Speaker
you know, shape what kind of work that gets done. And I don't want to, well, I mean, I do actually, if people are sponsoring and they say, oh, we want to be, you know, this is a problem for us or we want to be able to do that. I generally, you know, shift the backlog a bit to try and align with those needs. But if it was my employer, you know, suddenly it's not really my decision and I'm not sort of deciding, you know, what I think is best. I think there's actually going to be,
00:42:34
Speaker
a bunch of obligation there. And then I'm not convinced that I'll be building the thing that is best for, you know, the Gleam community and future Gleam users. Because in theory, you know, if all goes well, this project's going to go on for decades and decades and decades, you know, hopefully last longer, continue long after I've, you know, finished working on it. So, you know, what some company needs today is not super relevant. And I'd like to separate those things out as much as possible.
00:43:03
Speaker
So does that mean you're going for the like benevolent dictator for life? I always, I always joke that it's the malevolent dictator for life. Really depends on the author, doesn't it? Yeah, I mean, so I think that, I think Elm, Evan, the Elm chap did some good writing on this about,
00:43:25
Speaker
I think it's a really good fit for a language at the start, or not just a language for technical projects. Assuming you get lucky with a person to some degree and they make good decisions, it's really helpful to
00:43:41
Speaker
What can be more a cohesive decision-making process than a single person, eh? And not squabble and not get caught in these things. And that can get you to a point when you're mature enough in order to go, okay, and now it's much less pioneering and much more stewardship. At that point, I think you can spread out a lot more. We're not quite there yet. I think we're pretty close.
00:44:02
Speaker
I got the impression that Elm kind of burnt out before it got there, by putting all the pressure on one person. It's tricky to talk about what's going on with Elm, because I'm not privy to any of it, but it did seem at some point the updates just sort of stopped coming.
00:44:23
Speaker
He's clearly a very smart guy, but I speculate it might be Bernard, as he suggests. He seems to like working on things, like having quite a high degree of control over it, which everyone in that sort of situation is going to have a high degree of control, but I think delegation is so important. I'm very much an old open source nerd.
00:44:48
Speaker
I'm not old, but I've been an open source nerd for a long time. And as such, I think the community aspect of creation is super important. So much of Gleam is from the way that we manage the issues and the way that I try and interact with the
00:45:04
Speaker
you know the community it's about trying to enable people to get involved and build things whether that be you know this person did this amazing piece of work that would be really hard for me to do and it saved me loads of time awesome or if it's just this person made a pull request and it wasn't very good and we helped them get it there and it probably took a lot more time than if I'd just done it myself but
00:45:26
Speaker
they had a good time and now they're a member of the community like those are both wins those are both really good things and so like trying to grow trying to grow both of those things and all the other um you know interactions you have is like super important and i hope it means if i you know if i were to vanish tomorrow which i'm not going to um you know the board the board keep going
00:45:49
Speaker
So have you got people like contributing tools, contributing to the language itself, design decisions? How spread out from you is it?
00:45:58
Speaker
The majority of the compiler development is me, quite a large share, but the community is mostly focused around Discord at the moment, which is lovely. It's the friendliest, cheeriest bunch of people ever. And people are just there to hang out. Some people are there because they weren't really interested and involved in the language development and tools and all sorts of things. They're making great libraries and things.
00:46:25
Speaker
you know, there's a few academically types who do a lot, you know, write actually quite long form posts about different language features and how they can interact with each other and like, oh, well, and the references to papers and such. And then there's the people who just sort of use Gleam and they mostly just sort of
00:46:41
Speaker
They maybe share some libraries they've made or like show some pet projects they've got. And there's just some people who don't use Gleam and they're just there because they like it. Not it isn't Gleam. They like the people. Like they joined it. It's like, have you ever used Gleam? Oh yeah, I installed it once. I've never run it. It's like, you'll hit every day. But it's quite nice. I think it probably shows that
00:47:04
Speaker
We're doing something right, we're building a community if some people are just there because they like the community so much. Like, that's a good sign. Yeah, absolutely. It makes me imagine that you're eventually going to get sponsorship to buy like a hundred acre ranch, whole clean community, or just work the ranch. Where programmers go to retire, yes. Yeah, absolutely. When they're burnt out, the Louis Pilfold burnt out retirement clinic. Gone to live on a farm, yeah, I love it.
00:47:33
Speaker
But what is the future of Gleam? I mean, if I look at Gleam two years from now, will I see exciting new features? Louis Pilfold being the emcee of Gleamcom?
00:47:46
Speaker
I've made a tricky decision lately to do a lot less talking at conferences. I really enjoy it, but it takes me a long time to write a talk. I know some people can write a talk on the train on the way over, but maybe it's because I did a lot of theatre when I was younger.
00:48:04
Speaker
it always ends up writing scripts and rehearsing the thing and doing iterations on it and it just takes many many many hours and I could write a blog post in much less time than this and it would be read by much more people and then I can go and make a second blog post for a third or work on a feature and these sort of things and at this point in time where
00:48:27
Speaker
People are looking at Gleam. It's got a lot of momentum, which is really exciting. It's got more stars on GitHub than F-sharp, which I find bizarre. Wow. Yeah. How did that happen? So now is the time to push. So we've got to be really efficient with time. And that isn't confidence at the moment. But I'm hoping somebody will do a Gleam Conf, because I'll definitely do something for that. But in the next two years, we're getting
00:48:53
Speaker
We're finally getting to the point where the language is starting to look complete.
00:48:58
Speaker
That doesn't mean nothing will be added anymore, but like all the things that I think have been, you know, if there was a version one of Gleam, the language would have to have this, this, this, this, this mess. And that's always just seemed like this mountain on the horizon, but now it looks like a hill, you know, like it's still a very large, it's still huge, but like it's, yeah, it's on the horizon, which is really exciting. And then there'll be decisions about, okay, does that mean we do version one now?
00:49:24
Speaker
What does version one actually mean when the binary doesn't have just the compiler and language in it, but it also has build tools and a language server and all these other things? Can I have some of those be like zero point something? Or is the version one of a language only, disability guarantees are only for the language itself and it's not for the surrounding things? So there's lots of
00:49:50
Speaker
nuances to work out.
Interview Wrap-up
00:49:52
Speaker
And I'd like to have a good amount of just data on how people are using it and finding it in production. Because I feel pretty confident we've got a good design, but it may be after two years, people are like, actually, this thing sucks. That thing there is rubbish. And I go, OK, cool. We're going to fix that. And it'd be really nice if that was pre-won rather than, well, let's do one to two.
00:50:17
Speaker
because, you know, the artics, it would be the same amount of work, the upgrade process would be the same, but it would just feel quite different to the community, I think. So you want the major features to be ironed out in production for a while before you put the production stamp on it? I think so. I just want to have some, I just want to have like,
00:50:37
Speaker
More data. More data is always good, like for any decision. You know, if you're not entirely sure about something, just wait a bit. Have more, have more shower thoughts and talk to more people and do more experiments. Go into the Gleam community, spawn a number of actors and see which ones crash. Exactly. Yeah. Yeah. Now you're talking.
00:50:58
Speaker
Well, I am going to go and check it out because I've got the rest of the afternoon off. Cool. Louis, that sounds absolutely great. I'm looking forward to getting my hands dirty with a language that isn't as weird as Erlang, but has the power. Thank you very much for joining me on this. I'll speak to you again soon. No, thank you. Talk to you soon. And it's going to be great having you in the Gleam community. Yes, absolutely. Good plug. Cheers. Thank you. Bye-bye.
00:51:26
Speaker
Thank you, Louis. And thank you to Louis' cat, Nooby, for making a guest appearance there. With that, I think I am going to head off and kick the tires on Gleam. I've got some spare time at the moment, so I'm going to treat myself to a bit of programming. If you want to learn more about Gleam, head to gleam.run. That's the website with all the details. And if you're anything like me, you'll probably also want to look at packages.gleam.run to see what kind of library support it's got.
00:51:54
Speaker
Before you head there, this is the part of a podcast where I tell you about our sponsor, but we don't actually have a sponsor yet. So this week's episode is sponsored by having a nice cup of tea. Whether you're listening to this podcast in the gym, the kitchen, or on the way to a trumpet lesson, why not follow it up with a nice cup of tea and perhaps a biscuit?
00:52:17
Speaker
If you want to throw a biscuit my way and support future episodes of Developer Voices, please consider clicking like and subscribe and share and all those buttons. It would be great if you share it with a friend who you think might be interested. And we all know the algorithms are trying to figure out what interests people. So if you found this interesting, tell them with a click, please. And with that, I think we're at the end of this episode. I've been your host, Chris Jenkins. This has been Developer Voices with Louis Pilfold.
00:52:46
Speaker
Thank you for listening.