The Changelog: Software Development, Open Source - Run Gleam run (Interview)

Episode Date: April 24, 2024

This week we're joined by Louis Pilfold, the creator of the Gleam programming language. For the uninitiated, Gleam is a functional programming language for building type-safe systems that compiles to Erlang and JavaScript and it's written in Rust. We discuss the inspiration and development of Gleam, how it compares to other languages, where it shines, the overwhelming amount of support Louis is getting through GitHub sponsors, what's next for Gleam and their near-term plans for a language server.

What's up friends? Welcome back. This is The Change Log. I'm Adam Stachowiak, Editor-in-Chief here at changelog.com. Today, Jared and I are joined by Louis Pilfold, the creator of the Gleam programming language. For the uninitiated, Gleam is a functional programming language for building type-safe systems that compiles to Erlang and JavaScript and is written to rust. We discussed the inspiration and development of gleam, how it compares to other languages,

where it shines the overwhelming amount of support. Louie is getting through get up sponsors. What's next for gleam and their near term plans for a language server, a massive thank you to our friends and our partners at Fly.io, the home of changelog.com. Launch apps near users too easy. Fly transforms containers into micro VMs that run on their hardware

in 30 plus regions on six continents. Launch now for free at Fly.io. Our friends at Fire Hydrant offer modern engineering teams less stress from ring to retro, full end-to-end incident management, alerting, on-call, and of course, streamlining every aspect of your incident process. From webhook to alert trigger, to notifications, to incidents open, to retro tasks, to mean time, to X analytics, everything is inside FireHydrant for modern engineering teams. And what you're about to hear are real reactions from PagerDuty users when seeing signals from FireHydrant for the first time. PagerDuty, I don't want to say they're evil, but they're an evil that we've had to maintain.

I know all of our engineering teams, as well as myself, are interested in getting this moving the correct direction. As right now, just managing and maintaining our user seats has become problematic. That's really good actually. This is a consistent problem for us and teams is that covering these sorts of ad hoc timeframes is very difficult.

You know, putting in like overrides and specific days and different new shifts is quite onerous. Oh, and you did the most important piece, which is didn't tie them together, because that's half the problem with PagerDuty, right, is I get all these alerts and then I get an incident per alert. And generally speaking, when you go sideways, you get lots of alerts because lots of things are broken, but you only have one incident. Yeah, I'm super impressed with that because

being able to assign to different teams is an issue for us because um like the one the one alert fires for one team and then it seems like to have to bounce around and it never does uh which then means that we have tons of communication issues because like people aren't updated no i mean to to be open and honest, when can we switch? Okay, the next step is to go to firehydrant.com slash signals, assemble the team, and work the problem without a single swivel of the chair. Fire Hydrant delivers end-to-end incident management and on-call alerting for the modern software teams. Get started for free. Once again, firehydrant.com slash signals. We are here with Louis Pilfold from the Gleam programming language,

which you can find at gleam.run, which is one of those fancy new special TLDs that are getting so popular. Louis, welcome to the ChangeLog. Hey, thanks for having me. Good to be here. I feel like we almost had to have you because not only are we elixirists and Cleem is a cousin perhaps or related elixir somehow, but darn near everybody said we had to have you on.

We had this episode request from probably half a dozen different listeners, which is pretty high. And I was forward to do it anyways because I was like, this looks cool. So fulfilling our obligation to have you on the show. Happy to have you here. Almost had to have you. Almost had to. Almost had to. Not that

our hand was forced, but you're welcome here. Thanks. I don't know. Our listeners may have revolted had we not had Gleam onamon curious from your perspective. I mean, it's your language, but lots of excitement around it. What do you think is spurring said excitement? Why do you think so many people are into this? It's been wild. It's been like, there's always been a flattering amount of interest because the whole project started as me scratching an itch of mine to some degree you know it was always like there's all these languages and i love all of them but there's one right in the middle that doesn't exist so i started making that and it was really cool

just to see people start to go oh i like that too and you know join the discord or irc back in the original days and contribute stuff um but then we finally got to a point when it was ready and i thought yes it has everything we want i'm confident we're not going to break anything. It's time for V1. And then after that, it just exploded. I thought I was busy with gleam stuff before, but now it's just so many messages and so many issues and like not problem issues, but like, Oh, we should do this. We should do that. And pull requests and, that, and pull requests and people asking how do I do things on Discord. It's been phenomenal. So yeah, every project that's sticking on V1, yeah, maybe consider doing a V1 because it really reframes things

I think in people's minds. Yeah, especially with the language. So many experimental languages that people do kind of wait for that 1.0 for the author to say, okay, you can actually use this for non-experimental toys and trivial things. It's ready for prime time. Is this your first programming language or have you written other ones? I mean, what makes a programming language that's hard?

Because I've written loads of toy lisps and compilers and all sorts of things, but all sorts of hobby projects and and studying and that sort of thing but i guess this one was that originally but then sort of at some point went oh no this is real like this is good we should we should keep working on this so if you mean have i done anything that's why i feel that somebody should you know bet their their livelihood and their business on it no do not use any of my prior stuff for that but yeah i've rent lots of little compilers and do hickeys and stuff i'd love to have like three or four or five

of me because i've got a whole bunch of other language ideas that i'm just not going to find another six years to implement i was more thinking about it from the confidence perspective like where do you where would you get the confidence to build something like this because it isn't big undertaking as we get into the details you've built a lot of stuff. I mean, I don't want to necessarily call it batteries included. Maybe you do call it that. But we were talking with Jose Valim just a few weeks ago about Elixir and how he was talking about how difficult it would be

to start a new programming language today because the table stakes of tooling have really raised. And there's so many things that people expect you to have and new languages would have to build like the surface area is just large and so for me that requires from the author a bunch of confidence or gusto or you know where do you get that from yeah jose's completely right and i think it is part jose's fault because you know elixir turned up and there's loads of things that were kind of lacking in a lot of other languages

that Elixir just had. And so that raised the bar. And then languages like Go and Rust really came along and they raised the bar with the IDE language server type things. So they raised the bar again. So every time there's a new thing,

you go, oh, wow, we don't just need to have a compiler. Back in the day, you just have a compiler. Just give it to them and they go, all right, you figure out the build tool and the test framework and the editor

and the da-da-da-da-da-da, everything. Now you kind of want to have all these things built in. Or at least that's what I think. So like Gleam has, we've got a language server. That's the thing that Elixir doesn't have built in. But I don't know. I don't think it's about stubbornness. I think it's a mix of, sorry,

I don't think it's about confidence. I think there's a mix of things. For me, it was a stubbornness and I was like, no, I'm just going to keep going. You know, oh, I don't have that. Okay. Well, I'm going to keep working on that and just refuse to refuse to stop until we're there. And I think at the very beginning, being a bit foolish in terms of not realizing how big something is, not realizing I'm going to be working on this for a good, I don't know, six years or something prior to it being a first version. Or maybe not realizing the scale of your own ambitions. You know, the original project, Gleam started as me wanting to do a conference talk about making compilers.

And sort of grew wildly out of control from there. I was like, oh, hold on. Okay, so this works. What could I do with this now? And it just keeps going and going till i go oh wow this is a whole this is a whole useful thing something magical happens whenever we force our personal tastes into the world right because like that's how invention happens that's how innovation happens there you see a gap you see something missing you have a personal dilemma

right and you force into the world and my opinion, something magical happens when we do that as individuals, whether, whatever it might be, you know, it could be a language server or a language like Gleam. It could be a podcast that we produce, whatever it is, like put your personal taste into the world and see what happens. Totally. And I think that, you know, that, that, that personal connection for me is what makes a lot of, not just software, like you said, like, you know, podcasts and art and anything, like that's the really important bit. The person who's creating it or the people that are creating it

really have to care, you know, I think. And when you've got a team of people who are doing it because they're like, they really want this to exist, it makes a different thing than the team of people who are just like, well, we need a job. Like, I do need to pay my rent at the end of the day. And I found a nice job. It's cool that I can make this thing, but i don't actually care that much yeah well on the

topic of taste we are kind of taste functions ourselves right we bring we take a bunch of things in and then they get mixed around in our internals and then out comes our taste and i think with programming languages there's not just a, but also a borrowing and a flavor and inspiration from many different languages that go into the new ones, right? Like you don't just in a vacuum decide what's good. You're not going to stumble across that, you know, on your own. So curious your taste, where it comes from, programming languages you love, appreciate, and then eventually things that you decided Gleam had to glean. Ooh, I turned a phrase.

Didn't mean to. But yeah, where did your taste come from? So I think that's it. Gleam doesn't, lots of languages are, oh, I've got a really big new idea and I want to explore that. And Gleam isn't that at all. Gleam is, I was writing a bunch of different languages and i kind of wanted bits from all of them you know so you know for example when i'm writing go i was like i really wish i was writing erlang right now because i could do this thing or if i'm

writing rust and oh this is this is really annoying this thing i wish i wish i had that lovely thing from go like compile times or something i don't know and so gleam is just a mishmash of all the best things, which I think is really, which is why it's a really nice safe bet at the end of the day, because all these things have been proven, like the type systems, gosh,

well, that's like 20, 30 year old technology. Like it's not, it's, it's state of the art from the past. Yeah. We're still there.

We're still living there. And it's, it's still good. And we know it's good because we, we, it's been proved in production. So like the, the,

the combination of all the all the main inspirations, like Erlang and Elixir, obviously huge inspirations. There's a reason why Gleam is running on this virtual machine. Because it's brilliant. It's so good. And if we wanted to make that from scratch, it would have taken another, you know, six, 10, 15 years on top of that.

It's just a wonderful piece of tech. But then I think there's a lot to be said for sort of like the simplicity is it's kind of an overused word that, but like the smallness of Lua and Go. I really liked the idea that the languages that you can approach them and learn them really quickly and start doing useful things. You know, a lot of other languages are super powerful, but it takes a long time to run up to that. And I'm not sure that's always a good trade-off. Like I think for a lot of business uses, super powerful but it takes a long time to run up to that and i i'm not sure that's always a good trade-off like i think for a lot of business uses i don't really want to use the big complicated language i want to use one that's just like small

and gets out of the way and lets me do my job and and rust and elm are both super inspirational for the just how good the developer experience can be in those languages you know they're really good at saying oh you made a mistake look Look, here's what it is. Here's how you fix it. Here's why that's a problem. That's so good for learning, whether you're like brand new to the language

or you've been around for ages and just made a mistake. And also the Rust tooling, like Cargo's great. You know, I used to think that Mix was the best thing out there, but after using, you know, Rust came along

and just like made it one step better. So I'm hoping Glimm can be be one step better on top of that. So there's loads of good inspirations out there. Oh, Alpaca. Do you remember Alpaca? No. Way back. I think it was originally launched as MLFE, ML Flavored Erlang.

Okay. And it was an approach to add types to Erlang, and it was really cool. I really liked it, but it sort of got lost in the weeds way back while I was trying to write the standard library for it because I didn't have one. And then I kept finding compiler bugs and I'd report the compiler bugs and go, Oh, and then he got distracted by trying to like, um, implement type message passing. And then after all I was like, okay, I guess I should stop doing the writing the standard library for this thing. And I should like work more in my language so yeah loads of little i've stolen from

loads of great places yeah that's a good recipe great artist steel yeah i definitely want to come back to the package manager but what about a great artist steel is a great saying that we've all stolen and used, but what about this old saying, you know, Jack of all trades and master of none. Is there ever, when you have a language that borrows so much and brings the good parts together, do you ever wonder if it then becomes kind of this high, it's like a B plus, you know, like it's not mediocre, it's good in all these ways but it also doesn't have its own oomph did you pick that phrase deliberately you know do you know the rest of that phrase no i didn't then i do not know the rest i'm about to be embarrassed the whole the whole

phrase is jack of all trades master of none is often better than the master of one okay so like that expression is that you want to be you want to be a jack of all trades right that does ring it's like it's like the. It's like the Rust thing. Like, I love Rust, and Gleam's compiler's written in Rust, but there's so often, I just wish it didn't have the memory management stuff. Like, I just want to have a nice, fast

compiling to native language and not have to worry about lifetimes and all this sort of thing. So I think having a language that is more general works really well. Yeah maybe i'm wrong i'm pretty heavily invested in the gleam thing so maybe i'm not the best person to ask but i think we've got a really nice um sweet spot trying to find like the smallest set of use generally useful tools yeah and i guess it is to some degree specialized like this language has been made from you know over a decade

of my working in in the industry making you know boring business software you know websites and clients for things and background processing it's just the language that i wanted to use for those things i worked very briefly in like video games and music hardware probably not a good language for those places, but for their business systems, yeah, it'd be good for that. So how would you categorize it then? It's type safe, is it functional, is it object oriented? Can you kind of give everybody just the lay of the land

of when they approach Gleam, what are they looking at? So Gleam is a functional programming language that can compile to either Erlang or JavaScript. So it runs on the Erlang virtual machine, or if you want to run it inside a browser or on a phone or on a CDN or something, you can do that using the JavaScript backend. So a lot of people compare it to Rust, and I think that's because there's some like superficial similarities with it. So like the tooling is quite similar for both languages very easy to use but the syntax looks quite similar in that they both you know kind of look sea-like they've got curly braces and all that sort of stuff and they've got you know these very strong robust type systems they're both statically typed but i think it's kind of

misleading because i don't think of of gleam as being like a beam version of Rust. I think of it more as being like a functional version of Go. This idea has been like a small language that is fast and you can use for most of your business stuff. And you know, there may be times when you want to go to C++ or C or Rust or something, but for 95% of your stuff, you can use this and it will just enable you to, you know, get the job done. And I think that's what I want it to be. I want it to be a language for making stuff. What kind of stuff? Not video games necessarily, but web apps.

Well, I mean, you could make video games of it. Like, I think it's pretty easy to get caught up in, you know, going, oh, I need to have the fastest possible C++ thing for video games. But they made good video games in the 90s. They didn't have any of this stuff back then. And the computer was a potato. Some of the good video games in the 90s. They didn't have any of this stuff back then. And the computer was a potato. Some of the best video games in the 90s. Exactly.

You know, don't let technology limit yourself. Whatever you've got, make a video game with it if you want to make a game. All right. But I think most people are using it for web stuff, you know, web business stuff or like some command line stuff. Just anything that you might use Electro Erlang for, really. Or a bunch of the scripting languages, perhaps. So for web stuff, I'm wondering how big the community is,

because Elixir has Phoenix, Ruby has Rails, Python has Django, I could go on. Are there web tools beyond the standard library, or what does it look like? Does it have its killer framework or app, or anything out there that people can build with? we we don't have a a rails or jango but we do have a sinatra or a flask

i would say so we've got um wisp which is a nice framework but it's it's not quite as featureful as rails i think one day it could possibly grow into that but at the moment it's more the sort of like core of your backend web location. And that sits upon a, or that's most likely to be used with a web server called Mist. And Mist is really cool, I think, because Mist is, it runs on the Beam.

It's completely written in Gleam. And last time we benchmarked, it was the second fastest. Well, the first time we benchmarked it, it was the fastest. And the second time we benchmarked it, it was the second fastest web server on the Beam because the Elixir one just got slightly faster between the two benchmarks. But that's cool. And that's written

entirely in the type safe actor system that we've got called Gleam OTP, which is not a wrapper of Erlang's OTP. It's a brand, it's a completely new implementation. So that shows that we can make things that are just as fast and capable and powerful as as the erlang guys and the elixir guys yeah that shows a lot to me the thing that i think is really cool because like you know i'm a back-end person so i'm not very excited about like oh new back-end framework thing sure okay it does routing etc who cares sure the thing that's really cool is a framework called luster and luster started as being a uh i guess it's in the same sort of spaces like elm or react it's like a front-end framework so that it's taken advantage of gleam's ability to compile to to compile to javascript and then run in the browser and then

you can do all your like state updating stuff in the browser etc but then they extended it to hayley the creator she extended it's also be able to do server-side rendering. So you could use it in your backend with Wisp, for example, to render your HTML templates or that sort of thing. And then you could like mount bits of Lustre front-end code

on top of those templates. And then with the latest version, she's introduced server components, which is basically Elixir live view. So you can have, using Lustre, you can have the best of both. You can say, well, these bits we want to have, we want to work really well, we're really snappy, not worry about how bad the network connection is.

We can do that on the browser. Well, these bits we want to have that really nice Lustre developer experience, have to be connected to the backend and have all the data. Okay, we can use server components. And this stuff we want to be really simple nice luster developer experience have to be connected to the back end and have all the data okay we can use server components and this stuff we want to be really simple we're going to do server renting you can have one ecosystem write one code and adjust every single possible way of renting a front end you can do it's super cool that is awesome and i love the promise of one language on both sides i I've found that in the past, this was many years ago now, so tooling wasn't as good.

When I went to JavaScript for one language on both sides and Node.js, I didn't find the wins there that I thought I would by just speaking one language because the paradigms, the headspace was so different anyways. But having what you're describing there and having the Glean language on both sides seems like it would be potentially a very nice setup so the thing i really like is you know same language on both sides is cool but it's not as i think i had the same experience as you it's not as impactful as i sort of hoped it would be yeah it's really nice if you can do it i think the

thing that is really it really cool with Lustre is that, is that you can do both the live view style and the React slash Elm style. So you can, you know, if you pick live view, there may be bits of your app where you're like, oh, you know, this will be slightly better for the users,

like a better user experience if we could do this on the client. And they go, okay, if we're going to do it that way, we need to pick a second framework. Do we use React for this? Do we use Svelte? Like you don't have that point when you go,

okay, and now we've hit a hard line which our framework can do. And now we need to move into a different world. And the alternative is that you just do it in React to start with. And then you're not using your lovely Alexa live view and you're having like a slightly worse developer experience the whole time.

So like those hard lines go away to some degree with this, which I think is a valuable thing. Yeah, that sounds great. As a author, and I'm sure you have a team now of a few, so it's probably not yourself, but as a team, as a core team, does it slow you guys down to have to have these two compilers,

this JavaScript, and I guess what is the Gleam compiler output? Is it output? Is output. Yeah. Um, the original originally outputted originally targeted what's called core Erlang, which is an intermediate representation of Erlang,

which a bunch of early Erlang tooling used to use. Um, but then we moved it to Erlang source. So we out just output like normal Erlang code and then we invoke the Erlang compiler on top of that. Okay. So it's going from Gleam to Erlang to executable code. Yeah.

And then on the other side, it's going from Gleam to JavaScript, which then gets executed by the browser. Yeah, yeah, yeah. So is that a hamstring at all as you move forward? No, I don't think so, really. The language was originally designed in such a fashion so that it slotted in really well. We didn't have to make any big changes

or concessions to the language. And the compiler has been pretty easy to, there's not really been any trouble from maintaining the two things at the same time. It's almost entirely the same, you know, all the front section is the, the front section of the compiler is the same and all the static analysis are the same.

All the tooling and error reporting and everything is exactly the same. The only thing that's different is the same and all the static analysis is the same. All the tooling and error reporting and everything is exactly the same. The only thing that's different is these two code generators and code generation in Gleam is pretty simple because we don't introduce any additional runtime to either of the languages that we target. We just stick really close to the core language. And if you open up, if you get the Gleam compiler

to spit out some Erlang or some JavaScript, it looks like a human's written it. It's like pretty printed and it looks sensible. And, and, you know, I kind of wonder if you could get a, if you could just output it and sneak it by someone in a code review, like if you trick them into thinking if it's JavaScript or Erlang, like it might not be quite that good, but it's close. Might be better than the JavaScript that I write. Well, I mean, yeah, it'd be secretly Erlang-style JavaScript. So if you think Erlang's good, maybe. Yeah, there you go. So yeah, it's not with so much work.

The thing that has been a constraint coming from being split across these two ecosystems, or like sitting across these two different ecosystems, is the fact that Erlang and JavaScript both handle concurrency very differently. And so you've got two options here. You can either abstract over that by having a big thick runtime where you either introduce promises to Erlang,

which is probably a bad idea and everybody will hate you, or you implement actors on top of JavaScript, which I think a lot of people would really like, but then it means you've got to have a whole runtime that implements actors inside your JavaScript bundle. And languages that do this, like I think you can pull actors inside your JavaScript bundle. And, you know, languages that do this, like, I think you can pull Haskell to JavaScript, for example. And I think that just means that a very small Haskell app compiled to JavaScript is huge.

You know, I don't have any numbers off the top of my head, but like, let's just say, you know, it's like a megabyte of code to have, you know, a few Haskell threads talking to each other. Well, we don't do that. We just output normal promise using JavaScript, which means you've got to use promises in Gleam JavaScript code, which is a problem because then you've got the function column problem, which means you can't have, for example, a HTTP client that works on JavaScript be the same as a HTTP client that works on Erlang.

So there's a bit of a split here, but that's the trade-off you make for being able to interrupt really well with these two ecosystems. Well, Cloudflare's Developer Week is over, but there is so much to cover from that week. And I'm here to give you a roundup, so here we go. Their fully distributed serverless database, D1, went GA.

It now supports 10 gigabytes of data, and they added new exporting solutions and insight tools. HyperDrive, which accelerates your Postgres and MySQL databases, also went GA. You know that monthly workers pay plan they offer? How much does that cost? $5? Yeah, $5. And how much does it cost to completely speed up your database operations using Hyperdrive? Zero. Yeah, zero dollars. With Qs, you can now send and acknowledge messages from any HTTP client. They also added the ability to add delays. Yes, they added delays. Workers Analytics Engine, which provides analytics at scale. Flip the GA switch too.

They launched a brand new AI playground that lets you explore all the hosted models on workers AI, which, by the way, also went GA. That's right. Production grade global AI inference that you don't need to deploy all available seamlessly in workers or directly from a rest API call. They also announced a partnership with Hugging Face. So you can now quickly deploy an app using these models and fine tunes are here. Y'all that's right. They offer Laura support, upload your fine tunes from Wrangler and apply them to their most popular LLMs. There are so many ways for you to build with AI using Cloudflare.

It's awesome. And Cloudflare doesn't support Python? Wrong. They do now. Python Workers is here. From the same command using Wrangler, you can now launch a worker that can fast API, langchain, numpy, and more. R2 got event notifications.

You can get notified now when an object is created, changed, or deleted and handle that event in your worker. And who says you can't spell SDK without SDK? Craig did. And that means they have new SDK from Cloudflare's Developer Week. Check it all out for yourself at cloudflare.com slash developerweek. Once again, cloudflare.com slash developerweek. why the switch from erlang bytecode or whatever the format is to source code that seems like i don't know yeah why so there's a few reasons first that we did a full rewrite of the compiler

from being written in erlang to being written in rust and the reason for that what there's a few reasons. First, that we did a full rewrite of the compiler from being written in Erlang to being written in Rust. And the reason for that, there's a few reasons for that. One of them was that there was just a lot of tech debt from learning how all these things should work. And we go, OK, we've figured it all out now. It'd be a good point to draw a line and start afresh. And we got to the same place very quickly and fixed all the bugs and it was much faster. And because we're doing a rewrite, we're like, OK, should we continue to the same place very quickly and fixed all the bugs, and it was much faster. And because we're doing a reroute, we're like, okay, should we continue to use Erlang? Because Erlang's really good at making network services.

I don't think it's actually that amazing at making compilers. That's somewhere where I want to have algebraic data types and static typing and that kind of thing. So for me, it ended up being a toss-up between, what was it? Rust and OCaml, I think, were the final two. that kind of thing. So for me, it was kind of ended up being a toss up between what was it? Rust and OCaml, I think with the final two, but I went for Rust because I just, you know, with the state of the Rust tooling then and the state of the OCaml tooling, then I found Rust much easier to get stuff done with really. It's been a big success, but at that point we no longer had access to the APIs that you can use to easily output that intermediate formats. And it's very

easy to just output like source code. In fact's very easy to just output Erlang source code. In fact, it makes it much easier to write tests because you can just say, this code should compile into this code. And you look at it, you go, oh, look, that's an Erlang function with a case expression in it. Okay, cool.

And it seems like the ecosystem, the BME ecosystem is moving away a bit from that using that intermediate format. So Elixir compiles to Erlang as well. And it compiles to, um, I think it's called abstract forms, I think, which is a layer one above the one I was targeting. And I think LFE, the other big beam language that also did a similar switch for moving from the one I was targeting to moving one layer up. So I've moved, I'm one layer above them as well. So I think everyone's just sort of moving away from that one.

And they don't publish the documentation for it anymore, which makes me a little bit nervous. Yeah, that's a little bit ominous. Well, what about Gleam? Is Gleam a good language for writing compilers? I wanted everyone to write, I don't know, business things or games or whatever, but there's so many people making languages of Gleam. It seems to be a language person's

language. So yeah, there's people, I think we've even got bindings to, I can't remember, it's QBE, I think it is, which is like an alternative to LLVM. So they're like writing Gleam programs to compile to native and stuff, which is very cool um so i think it is good for writing compilers people seem to like doing it why did you want to focus on business stuff and games like what made that be your focus oh well it's because that's the business stuff i mean games because it's cool i like i like when people make art and like games games are a prominent form of electronic art that's awesome so i want i like art more art is good but the business stuff is because like that's what i make my money with i spend you know i spend i spent five uh days a week you know eight hours a day making some i don't know web thing or payment processor or something and i was always like i

wish there was some other the language that i want for this just isn't quite there. At least I can't find it. And while if I was making something, you know, if I was trying to mess about with some art or some music or something, it's like, oh, I found like, oh, Godot's script is really good for this. Or like Rust is really good for this. And maybe that's because I didn't, I don't have enough experience in those worlds to say, oh, actually Rust isn't very good for it. I think I can make a better video game Rust or something. I just didn't feel the same need to try and solve those problems. While Gleam is like, this is what I think people need to make their lives easier,

to remove some of the stress of the work we've got to do every day. Are you still building these businesses? No, not really. No, not really. No, not really. That's a good response. Well, I was super lucky. At some point, someone was like, oh, you should sign up for GitHub sponsors.

And I went, really? What for my silly little open source language thing? Okay. And then people started signing up, which was amazing. And not last December, but the December before, I had enough, I had enough money coming in every month from that, that I had managed to like fill up my savings again after, you know, cause I kept quitting my job to work on Gleam. And then I'd run out of savings and go,

I've got to get a job really quickly. Oh, it's looking comfortable. How do I pay rent? And then I'll get a job and then I'll do the six, you know, stick there for six months and do the same thing again. And I'd managed to build up the savings enough to be like, oh wow, I've actually got a little buffer. Let's see what happened if we go full-time and gleam and like try and actually try and live off it this time. And since then I've just been working on gleam full-time, which is amazing. I do think it's really important to try and find business-like things to work on. I'd like, or just gleam things in general, because I remember, who was it? Matt's the creator of Ruby.

He would say, I'm not a Ruby developer. I'm a C developer who worked with Ruby, which, you know, if you spend all your day working inside the interpreter or the compiler, you may not actually use your language very much. So I've tried to spend as much time as I can writing code in Gleam. You know, like we've got lots of tooling

written in Gleam and websites and little data automation things. Because if I don't know what it's like to use the language, I'm not actually any good at the helm of this thing. Like somebody else should be making the decisions

if I haven't used it as much as all the users have. So what are you building with it? Like specifically? What am I building? Oh dear, what was the last thing I built? Like tooling, like the things you just mentioned, like what are some specifics?

Yeah, okay, so we use the Hex package manager. And Hex is the package manager for the Beam ecosystem. It was originally made for Elixir, but now all the Beam languages use it. And so they've got a website, and you can search for packages on there, but it just shows you, you know, all 18,000 packages or 19,000 or however many it is.

But if you're trying to find a Glean package, that doesn't work very well because there's 300, 400, something like that. So I made a web app which scrapes their API, works out which one's a Glean, and then allows you to have a searchable interface for finding Gleam packages and then finding their donks.

Donks? Finding their docks and that sort of thing. Finding their donks. Donks are kind of music that's very popular around here. No, we don't have any Gleam dance music yet. Oh, really? What kind of music is it? I think it was originally called Scouse House

because it was like a techno house music that came from, where was it? Liverpool, Birmingham. Gosh, I'm having a blank. What is, what's a Scouser? Don't ask me. I'm saying very English words at you and you have no idea. We're just staring off into the abyss now.

What's a Scouser, Adam? Yeah. Anyway, God, I had a slight mind blank then. All the English people are going to be laughing at me but another thing i made was so lust of that framework i mentioned you got to write lots of html in it but it doesn't use like a jsx type syntax it's got its own dsl and so that means that works fine there's nothing wrong with it it's just um but it means that you can't like copy and paste a html example say for example you're using, gosh, I don't know.

This is going to date me, but let's say you're using bootstrap. I don't think anyone uses bootstrap anymore. And you want to copy out the example of how you make a form. And then if you can't paste it directly into a gleam code, cause it uses a different syntax. So I've made a little widget where you paste in your HTML and it gives you back gleam code. Like here's the same thing in the, in the, in the luster syntax. I guess the packages lives at packages.gleam.run. Is that the... Yeah, that's the little searchy website. And it's just like a front end for the full Beam package manager.

And Lustre is L-U-S-T-R-E, right? Yes, that's the one. And that's living off of Lustre Labs. Is that something that was different, like a different thing you did? Is that correct? Is that right? So I don't make Lustre. I'm a light user and a fan. But that's all made by Hayley and her contributors.

I see. It's quite funny because it's getting so big that everyone assumes that either I made it or that she made Gleam. Which one is it? It's all too confusing. Yeah. It's cool.

It's cool that the community is growing beyond you. Yeah, it's great. But I just keep getting all these reports being like, how do I do this in Lustre? And I was like, I have no idea. I'm not sure. And Haley is Haley Thompson. Just everybody knows.

Yeah, yeah. Haley.dev Just everybody knows. Yeah, yeah, yeah. Haley.dev. Long form. So on this package manager, you mentioned if you like mix, you'll love cargo. And then I built gleams to be better than cargo or even more. I know you didn't say that. It's a cargo ripoff.

It's a cargo cult. Oh. But now you're saying you're using hex and so i'm gonna tell us more about how it works like what yeah so it's the interface of of the gleam build tool creatively named gleam is uh very similar to cargo in so i'll give you an example if you want to use mix you start your project you you clone it you go into it and then you write you'd run mix depths.get to download all your dependencies and then you can run like mix test etc in the rust world you don't need to run cargo download depths it just goes oh you don't have your depths

yet and you want to compile i'll download the depths for you gosh why didn't they all do that that's such an obvious you know that's such an obvious thing in retrospect. So that, you know, it's all those little things that we've stolen from cargo, but it uses the, you know, it talks to the same package manager system that the, you know, mix does, for example, and rebar the Erlang tool does. So we share the same packages and the Gleam build tool knows how to compile Gleam. It also knows how to compile Erlang. It knows how to compile Elixir. So you could use the build tool and not use Gleam at all if you wanted to

and just like have a whole mix project. No, have a whole Elixir project in there. And the same thing we can like depend on, we can depend on dependencies that are published with Gleam or Mix or Rebar or Rebar 3. So we try and like enable you to use as much of the ecosystem as possible. Because, you know, that's a big part of why Gleam or Mix or Rebar or Rebar 3. So we try and enable you to use as much of the ecosystem as possible. Because that's a big part of why Gleam is good,

is that this existing ecosystem is fantastic and we want you to be able to use it. So can you use pretty much anything? Because I was just using an Elixir library today called Floki, F-L-O-K-I, which is an HTML parser and stuff. The HTML parser, yeah. Yeah, it's a popular one

and pretty good one i wish it did more manipulation type stuff but anyways not your problem louie why doesn't it do more now i'm becoming one of your one of your roster uh people so could i just use that from gleam then just be like floki dot whatever for my gleam code or how does that work yeah yeah that's interesting you picked that one because that one for some reason has one Glean file in it and has done for years. You can't use it, but like there is just one single Glean file hidden in the Flucky source tree.

So you can add it as a dependency. The build tool will automatically compile it for you, but you will need to write some bindings for it. So the reason for that, so like in Erlang, you can just say, oh, well, I'm using the Elixir package. It defines a module called this. I can just do like the name dot whatever. And the same thing in Elixir, you can just say, oh, there's one in Erlang one,

it's just called name dot function name. You can't do that in Gleam. And the reason for that is that everything is completely typed and type safe in Gleam. And we can infer everything from looking at Gleam code. Like you don't need to, we say you should write annotations, but you don't need to. Like we can just tell everything by looking at the code, but we can't analyze Elixir code. We can't analyze Erlang code, right?

So we need you to say, trust me compiler, there is a function, there's a module called this, and it has a function called this and you know maybe like it's called flocky it has a function called pass html and it takes in a string of html and it returns a i don't know a list of dom nodes or something like that and the compiler will go okay cool i trust you and then you can use that defined function in your code so there's code. So there's a bunch of, there's a handful of packages in the package manager that are just like, you know,

if someone wanted to use Flocky, someone might write Glocky, I guess people like to put GL before the names of the package, which some people really hate, but I think it's really cute, which are just like a little facade over some existing really good elixir or erlang package so there's a little bit of api design to do there you could just import them one for one but i think there's more value in if you take a little bit of time and get okay so what what exactly would a good api look like for this in like a typed context because what's really good for a dynamically typed language may not necessarily be the best API design for a typed language.

So I tend to write my applications that use a Elixir Erlang library. I just, in my application, have one module that wraps it, and then over time, I might slowly make it a bit better, and then when I go, actually, this is nice now, I might pull that module out and put it on the package manager. Pretty cool. So you have access to these things.

They just require a little bit of decorating or wrapping or just some, there's some ceremony involved. And if you do it well, there's actually some benefits there. Yeah, and those bindings are unchecked. You say, it's called this. Well, if you made a typo, it's wrong. Or if you got the type annotation, it's wrong. well if you made a typo it's wrong or if you if you got the type annotation it's wrong and then you might get a runtime error and you know i think that's quite

a good trade-off you get you know you get this whole awesome bit of code that's written in another language but you might get runtime error okay that's sort of slightly undermines what you know gleam is going for you know it should always work but then you know exactly where to look like oh it crashed oh it must be in that you know it where to look. Like, oh, it crashed. Oh, it must be in that, you know, it must be at that point over those bindings. It really narrows the amount of space you have to spend debugging your program. Well, it gives Gleam users access

to thousands and thousands of packages with a little bit of work that they wouldn't have access to. And like you said, something around, you said 400 packages currently that are like Gleam native-ish. ish yeah good question how many are there uh three and a half hundred so it sounds like gleam's in a very good position by the way to our listener if you like to trailblaze a little bit uh which there's probably a lot of low-hanging fruit of things that could be written in gleam even just

ported like really nice libraries where you could wrap it and continue to do the Elixir dependency, or you could write one that's Gleam native and provide that value to the community. There's probably lots of opportunity there. You could be like Haley, right? You could be the next Luster author of the next thing, or like Chris McCord, right?

You could be writing the Phoenix that might bring Gleam to thousands of other users. So lots of opportunity, it sounds like, where it currently stands. It's how I made my name in the open source world. I started writing Elixir just as V1 came about, and I was writing Ruby prior to that. And so I was like, oh, I really wish there was a linter.

So I made the first Elixir linter that was later forked and became Credo, which is the main one and then i wrote the after that i wrote uh the first elixir formatter which thankfully didn't get used and well did get used but then um they made a new one for the official one because it's much better than my one but yeah it's it's really cool being in a young ecosystem because it's just like so much opportunity to make things and sort of like decide what the shape of this whole little world should be. On the FAQs, which I am thankful for,

I wish they weren't stuck down in somewhere else. I kind of wish they were a little bit like maybe first class citizen in the navigation potentially because they're very helpful. And I see that you compare Gleam to Alpac as we talked about Camel, or sorry, Caramel, not Camel, Elixir and others. And we talk about typing, stack typing, and it compiles to JavaScript. Why don't you compare this to TypeScript? I think a lot of those, how does it compare to this questions came about because people get asking me about those specific languages and people don't ask me that question much anymore which is interesting i think that i think now

it's mature enough and there's enough people taking it seriously people no longer have people no longer ask like why does this exist you know people looking at oh it's a thing okay and they don't ask you know why does this exist if, you know, caramel exists? Why people are more interested in like, okay, how do I do this? And so that's sort of the question that comes up. It could be interesting to do a, you know, to compare it to TypeScript. They're quite different languages. I think that might be slightly better for this, which they're not quite ready yet, but there's a section on the website called Cheat Sheets,

which attempts to teach attempts to just show you the very basics of the language really quickly by comparing it to a language you know. And I think there's a pull request for one with TypeScript. They could all do with a lot of love, actually, all of the cheat sheets, but I'll get to it at some point. Like Gleam for TypeScript users, essentially.

Exactly, yeah, yeah, yeah. Because it started, I think, with just Gleam for TypeScript users essentially. Exactly. Yeah. Yeah. Yeah. I think because it started I think with just like Gleam for Elixir users because

it was like these are close enough. Here's you do this. Here's you do this. Go write a program. But they're kind of a nice way to just sort of get a general feel for

a language I think. What's up, friends? This episode is brought to you by ImageProxy. ImageProxy is open source and optimizes images for the web on the fly. It uses the world's fastest image processing library under the hood, LibVeeps. It makes websites and apps blazing fast while saving storage and SaaS costs. And I'm joined by two guests today, Sergei Alexandrovich, author, founder, and CTO of ImageProxy, and Patrick Byrne, VP of Engineering at Dribbble, where they use Image Proxy to power the massive amounts of images from all of Dribbble.com. Sergey, tell me about Image Proxy.

Why should teams use this? Everyone needs to process their images. You can't just take an image and just send it to users' browsers because usually it's a megabyte of data. And if you have lots of images like Dribbble does, you need to compress and you need to optimize your images and you need them in the best quality you can provide. That's where ImageProxy shines. Very cool. So Patrick, tell me how Dribbble is using ImageProxy. Being a design portfolio site,

we deal really heavy in all sorts of images from a lot of different sizes, levels of complexity. And when we serve those images to the users, those really have to match exactly what the designer intended. And the visitors need to receive those images in an appropriate file size and dimensions, depending on whatever their internet connection speed is or their device size is. And that was just a constant struggle really to really thread that needle throughout the course of the platform, using a handful of different connection speed is or their device size is. And that was just a constant struggle really to really thread that needle throughout the course of the platform using a handful of different tools in maintaining that right balance of a high degree of fidelity, high degree of quality without

sacrificing the visitor's experience. And when we were exploring using image proxy, we were able to spin up using the open source version of the product, a small ECS cluster to just throw a few of those really tough cases that went through our support backlog, looking at some of the cases people were reporting. And almost to a T, we aced every one of those cases. Wow. So it seems like ImageProxy was really impressive to you. Yeah, Adam, I just have nothing but positive things to say about using ImageProxy. The documentation is crystal clear. Out of the box, it does everything you need it to. Tweaking it to meet your specific needs is incredibly easy. It's wicked fast.

It deploys real simple. And our compute costs have gone down over the open source tools that we've used in the past. Even including the ImageProxy Pro license, it still costs us less to use and gives our visitors a better experience. So as an engineer, I like using it. And as an engineering manager, I like what it does to our bottom line.

So ImageProxy is open source and you can use it today. But there's also a pro version with advanced features. Check out the pro version or the open source version at ImageProxy.net. The one thing I love so much about this is that no matter which you choose, the open source route or the advanced features in the pro version, you use the same way to deploy it. A Docker image, one that is from Docker Hub that everybody can use, it's open source, or one that's licensed differently for those advanced features,

that's the same delivery mechanism via Docker Hub. It's so cool. Once again, imageproxy.net. Check out the demo while you're there and check out the advanced features for the pro version. Once again, imageproxy.net. What's up, friends? As someone who's always been mindful of

what I put in my brain and what I put in my body, I was so excited to get a chance to work with Factor. I've been a fan of Factor for a while and recently had a chance to get them on as a sponsor. Now this is a little off center from our normal sponsor style because hey it's about food but I believe you are only as good as what you put into your body. And that begins with food. Eating better can be easier with factors, delicious, ready-to-eat meals. Every fresh, never frozen meal is chef-crafted, dietitian-approved, and ready to go in just two minutes. You'll have over 35 different options to choose from every week, including CalorieSmart,

Protein Plus, that's mine, and Keto. Also, there are more than 60 add-ons to help you stay fueled up and feeling good all day long. Now, what are you waiting for? Get started today and get after your eating goals. Two-minute meals, pancake smoothies, no prep, no mass meals, flexible for your schedule. Factor is the perfect solution if you're looking for fast, no prep, no mass meals, flexible for your schedule. Factor is the perfect solution if you're looking for fast, premium options with no cooking required. And of course, you can sign up and save. We've done the math. Factor is less expensive than takeout, and every meal is dietician approved to be nutritious and delicious. So head to factormeals.com slash changelog50 and use our code changelog50 to get 50% off.

That's right, 50% off. That code again is changelog50 and go to factormeals.com slash changelog50. That's F-A-C-T-O-R-M-E-A-L-S.com slash changelog50. That's F-A-C-T-O-R-M-E-A-L-S dot com slash changelog50. How did you get all these sponsors? You got so many sponsors on GitHub sponsors. I mean, 258 currently, 97% towards your goal of the nice round number of 256. I'm not sure how 258 is almost 256,

but maybe that has to do with recurring versus non-recurring or something. Right, yeah. So here's the question. On GitHub, if you look at the number of sponsors, they list two different numbers and they don't match. I have no idea how they calculate. Just a bug, maybe.

This is Microsoft. I thought it was like maybe it's eventually consistent, but it's fairly consistently wrong. I don't know what's going on there. Yeah, who knows? Either way, you're doing great. Yeah, I think, gosh, I don't know. It's a lot of things.

There's a lot of luck i think there's a lot of my having been in the beam world for you know a good while i was i was known in the alexa space prior to being prior to the whole gleam thing starting to take off i think a lot of it is from you know i put a lot of work not just into the the you know making the technology but also a lot of work into making the community you know it might be maybe about half and half or so well since v1 i do much less coding and a lot more talking to people but um it's all very well and good having a good piece of technology if it doesn't have people surrounding it you need you need to have people who can help each other learn and people who can make the things you can't make.

And you want people to have a good emotional connection to the thing you want them to use, right? Not just because they like the experience of using technology, because when they're hanging out with their peers, they're having a good time. So like making a really good environment that is like welcoming and learning and friendly is, is, is, um, you know, one of the main things I think about. And I think that by accident, you know, really paid dividends with making people want to, you know, give me $5 a month. And, you know, if enough people give $5 a month, then we can afford to keep doing this thing, which we have been able to for the last, you know, year and a bit, which is fantastic. There's also like one big,

one big sponsor, which is Fly, the deployment platform. And they, they got involved a bit before I went full time and they've been super awesome. If it wasn't for them, I wouldn't have been able to go full time as early as I did. And like the reason why we're V1 now rather than like V1

later is definitely because they got involved. They've been really supportive. Yeah. We share a similar if they weren't involved story. We're very big fans of Fly. Our home is on Fly as you know. I say that on the podcast. That's our home, Jared. It's our home. Big fans of Fly obviously. And Kurt and team

and all them. Yeah, they sponsor us. Yeah, for sure. And I just think that all them, you know, just, yeah, they sponsor us. Yeah, for sure. So, and I just think that all companies should do this, right? Like all technology companies are building on, on, on a bedrock of open source technology that's maintained by a bunch of people working when they've got a bit of time. And I just, I just like, I find it so frustrating. What would this industry look like if all of these things that we rely on had a half decent amount of funding, right? If all of these companies spent like a coffee amount of money or an IDE subscription amount of money on these little open source projects, everything would work so much better. But yeah, there's a whole battle to to win there but i'm sure the

flies it's just preaching to the choir there louis preaching to the choir i agree with you i don't know if you answered jared's question though how did you do this like how did you get these many sponsors we've talked around it but not the direct like how in the world did you do this because i mean that's a lot i wish i knew the i wish i knew what the magic button was because i just keep pressing that damn thing like give us 30 second secret sauce version. Just tell us exactly how to do it. The prescription. I just, I wish I knew just like, I guess just be nice, ask for help a lot and hope for the best. And most importantly, be lucky. I think that is the big thing. Like I, I would love to have a good idea of what the thing is.

I, I kept trying different things and I've got charts of like how, how much activity there is on the website and how many sponsors I've got and how much money I've got coming in and I'll try something and nothing will change. And then I will, and then I'll do something else. And that will, that will change it a bit. I was like, I don't know why, why did one work and the other didn't, I just, I can't quite work out. The thing that's been amazing has been when V1 happened to Twitch streamers, picked it up, Theo and Prime, like T3.gg,

T3, yeah, T3.gg is Theo. And when those two, you know, put the word out about Gleam, everything exploded. Like all of my graphs were just like just shot up into

into the sky and those two those two gents um you know doing 30 minutes of coverage each did more for any of my metrics than i've managed to do in three years so i don't know get get lucky and um to hope that the right person notices that you like it. When Fly noticed, that was a huge change. When these couple of streamers noticed, that was a huge change. Just keep rolling the dice and talking to people and hope for the best, I guess. What's the next level? Is this sponsors-driven support the way to go

for the foreseeable future? Is there a next level for Gleam, the language, and you, the person that's primarily behind everything? I don't earn as much as I would if I was doing a developer job here in London. I would like to get my income up to the point where I could pay myself that full salary. And then I would really love to be able to start employing

or like outsourcing or contracting or something the core team members. Like there's a few people, like the first one is probably Jack who lives in Italy. He's an amazing guy. He does so much work. And like, I would just love to be able to like pay him for the amazing work he's doing.

And yeah, it's a bit daunting working at how we'd get enough money to be able to do those things. But everything's moved so fast since V1. It makes me think, oh wow,, actually, this is really doable. You know, things that didn't seem possible before do seem possible. There's lots of avenues. I think sponsorship's always going to be a big part of that.

And I like sponsorship because it really feels like an open source thing to me. This idea that if you want something, you support it, whether it be by fixing a bug or like testing something or just like giving them $5. That's awesome. I really want to find ways to get more corporate sponsors like Fly. I think as more companies start to like invest in and use Gleam, we could definitely, I think we definitely naturally get more who want to support in that way. But I also want to explore doing some other things

like having maybe like a gleam enterprise which is the same as support but it's just wrapped in a way to help you get to get it through procurement but that but things like premium educational content there's a there's a bunch of open source projects that have something like that where they just have like some amount of you know educational content or references and stuff like that. And then you pay a small for a company subscription amount of money, but large for an open source project amount of money. And that gives you access to that.

And from talking to projects that do this, it seems that a lot of them, the companies don't actually seem to use it that much. It's just the companies like buying things. So I want to sort of play around with with that interaction a little bit you know they it's hard for a capitalist company to just say yes we'll give you some money but it's easy for them saying oh yes we'll give you a few thousand dollars you know every x amount of time such that we can have this relationship with you right we have this this content so that's something to explore other things are

i've got a friend working on a merch store so if you want to buy your gleam keycaps and gleam t-shirts and gleam stickers that'll be uh that'll be a thing we can hopefully do soon i have no idea if that will be if i actually make money or not but i just love the idea of people having like little gleam logos i would say yes but no but uh yeah we have been selling merch for a long time, and it's fun. I'll say that about it. It is fun. It's fun to do.

It is not the pillar for which we stand upon. It is marketing and fun. Yeah. I would say, what do you do then? What kind of efforts can you personally make or team members within Gleam can make to make inroads into corporate sponsors, not just sponsors, like you said, but those who use it and get value so they give back to it.

Because I think of some obvious other ones I won't name, but there's several out there that when they utilize something, they tend to give thousands, like you mentioned, back to that community because there's that relationship that we want to do this so that it does remain active and we use it

and so we get benefits of it. How do you, do you make a deck? Do you cold call? What do you do? I think the first thing we've got to do is go to get those users, right? So like Gleam is really new. V1 came out a month and a half ago.

And that means we don't have, there are production users, which that's exciting. That's really cool. But we don't have there are there are production users which is that's exciting that's really cool but we don't have those ones that are you know that are not tiny tiny little handful of people companies or it's a company who will just have a very small amount of gleam in the in the in the production stack we want to keep um keep working on experience and making it better making easier to learn and use gleam and then hopefully in like gosh i don't know 12 18 months time we'll have some companies who are saying yes okay we will happily publicly say that we have been using gleam this much over this amount

of time and it's been really good for us and then i think that will how i think that'll have two effects first it will encourage other companies to like, you know, both invest and to talk openly about using Gleam. But it will also, you know, hey, we should probably like talk to these companies and, you know, work out what those next steps are, right? And I think a lot of the people who are, you know, with new languages, companies don't decide to do things. People decide to do things, right?

And the people who decide to put gleam into a company are going to be these people have this sort of emotional connection to to glean they think that it's good or they like it or they think it's valuable for some reason such that they're willing to take that risk whether it be you know whether they're the cto of a company and they go okay i'm going to risk my my my company on this or they're a you know just an engineer they want to say yes i'm going to risk my you know i want to put this, or they're a, you know, just an engineer and they want to say, yes, I'm going to risk my, you know, I want to put myself forward in the team and say, yes, I think we should do this. I'm going to propose this thing. So they're going to be, you know, pretty connected to Gleam. So I reckon I'm probably going to know who they are.

You know, they're probably, they're probably going to be in the community, right? What are some of the obvious places that companies may be having code out there or applications out there that could just benefit from Gleam? You know, either Sprinkled In is a new Greenfield project. Would it be Greenfield projects? Would it be rewrites? Would it be legacy code that sort of like needs to be modernized? Where does Gleam fit in for that kind of scenario to kind of give people a buffer to kind of go against? I'm not sure really. Like it's tricky because I wouldn't say, you know, you can take a language like Zig, for example,

and there's a really clear way that you would slot that into an enterprise. You would say like, you've got a big, difficult to compile C project that you need to cross compile and, you know, distribute around. Oh, obvious, you're just going to use Zig for that. We don't have that.

We're just like, we're just a really good language, I think. So you can kind of use it for anything. So I think at that point it is less of a question of like, what is Glean good for? It's more about spotting opportunities for inside, whatever the circumstances of that business are for, for introducing something new. Like I know one company wrote a, what do they do? They wrote a HTTP proxy. They needed to write a HTTP proxy and someone went, oh, I'm going to do that in Gleam.

And now they're using it for that. I know a company, they, what do they do? I don't know how to explain what they do because it's too complicated. But for their internal accounting tracking system thing, I don't know what it is.

I don't know. Because it's an internal tool, they could just make a new thing. They just made it in Gleam. So I think it's more about finding the opportunities inside the business than being a specific Gleam thing. And if the people inside those businesses

were big fans of Rust or Go, well, they could probably make an argument for using those things instead. So I think the really valuable thing is to make it really obvious that Gleam is a really good, solid, solid choice, both from like an engineering perspective, but also from a, you know, from the point of view of the company,

I want companies to look at the Gleam project and go, okay, that looks really solid. You know, Oh, look, it's, it's, it looks like it's well-founded. So it looks like it's well-funded. It looks like the team are really responsive. It looks like there's good documentation, you know, that kind of thing. You compared it to Go earlier, if you can remind me of your comparison. And does it make sense to say if they're reaching for Go for a scenario to consider Gleam as well in that consideration? I think in a lot of circumstances, yes, especially in web.

An obvious difference is that Go is so much more mature than Gleam, so we're not quite there. But I think there's a lot of similar notes in Go to Gleam. I think there's a lot of similar aims as well. It's a language that is designed to enable engineers to learn it quickly and just get on with making things. And things that may possibly be difficult to do in Python or Ruby or whatever they're using previously.

I think the thing that is different is the execution of what is a simple, practical, small language? And they've gone on this, what to me feels like kind of old-fashioned in a simple, practical, small language? And they've gone on this, what to me feels like kind of old fashioned in a lot of ways, procedural language, you know, like null pointers and mutability and all this sort of stuff. And I've gone off in this functional way.

So I'm hoping that, I think there's a lot of space for people who use Go but aren't particularly enamored with Go the language. They just like the attitude of Go, being able to get stuff done i would i'm hoping that we'd like the functional curious ones of those we can like move over into the into the beam world and use use um gleam to do that what's next for the language you've reached 1.0 i think you've reached 1.1 and surely you're not just pushing the community and

the reputation and the business side forward, but the language itself. So what are you working on there? What's coming down the pipeline? What are you excited about? Maybe Gleam 2 or Gleam 1.5. I don't know how your versioning works, but we know how 1.0 works, but that's about it.

So one thing I want to do with Gleam is I want to not add lots of things to it, to the language at least, to the core language. I think it's really, I think I see this thing of languages reaching V1 and go, that's really nice. And then you see like, oh, six months later, they've added this thing and six months later, they've added this thing.

And it just like keeps getting bigger and more complicated. And most of the time, do you need those things? I think everyone was pretty happy at V1. Like, did you really need to? So I want to hold off on adding things to the language itself because i think i think a small concise really well considered feature set is a feature in itself you know not having to learn all the different complicated new operators and ways of doing things is a feature so i don't want to make the language more complicated the thing that we're

really focusing on is the language server so we've've got a language server, which, you know, the fact that it exists first party and a V1 language, I think is pretty exceptional. However, compared to a lot of other language servers, it's super immature. Like it's easily the most immature thing in the Gleam world. And I want it to be, you know, as good as the one that you find in, you know,

Rust or Go or Java and all these sort of things. That's quite an ambitious target, and I think we can get there. But all this energy that we might be pouring into new Glean features, we're going to point to tooling, because I think everyone would benefit from having excellent tooling. When you focus on this language server, what are the things you think are most important

to have a good language server? There's obvious good reasons why you should have one in general, but what are the things you think are most important to do first? There's loads of things that people just expect a language server to have. And if it doesn't have it, they think it's broken. Like, autocompletion of functions and variables and stuff is something that we don't have yet.

And everyone as a, as a result thinks the language server doesn't work, even if they tried any of the other features, you know, they would, they would see they do work. So we need to, to make sure we've got,

we've got go to definition, go to reference, auto-complete absolutely everything. And, you know, all these things people just expect. And then after that, we need to start thinking everything and you know all these things people just expect and then after that we need to start thinking about um you know things that make it really special i think so gleam is a language based around static analysis we know loads about your code and so i think we

can do loads of really cool refactorings you know i think like being able to do like um code mods and refactorings and code generations inside your editors can be this really powerful thing which we can deliver. And I think it will also scratch a lot of that itch that people want for macros and metaprogramming for. I think a lot of that is just about removing boilerplates

or things that are slightly tedious. If we could just help you write that code, that will make a lot of those problems go away, I think. I think maybe we'll find out. I imagine the generation is probably like, as the idioms around idiomatic code changes, that's easier for you to say,

well, this was the old way, this is now the new way, this is the evolved way, right? And I guess the next question around generation is, is there anything in particular you're doing that's helping you be more playful or I suppose more useful in an LLM or a language model that's helping a developer learn Gleam or use Gleam? I don't know.

A few people have tried to do stuff with LLMs and no one's got any particularly amazing results yet. It's not my area of expertise, so I can't speak with authority here, but I think it's just that we don't have quite enough content to be able to reliably put out good answers yet. But from my point of view,

I'm not very invested in improving that yet. And the reason for that is that we don't have so, you know, there's a lot more activity now since V1, but there's not so much activity that we can't keep up. And if someone is going to ask a question, like, how do I do X, Y, Z? I don't want them to go to an LLM.

I want them to ask us because they'll get a good answer straight away, I'm confident. And then we know who they are. And like, they've started to build up a, you know, they've started to feel like they're part of this community rather than being like've started to build up a, you know, they've started to feel like they're part of this community rather than being like, oh, I'm just,

you know, Gleam is this tool and I learn about it through talking to this AI model. And I'm not actually in any way invested in the community. I, you know, I want people to go, oh, wow, I asked and not only did I got an answer, these people are really nice. Okay, well, I'll hang out with him more and then they get more engaged and more involved in the, I think

they'll stick around for longer. Is your middle name by any chance, uh, does it begin with L? You could at least be LLP, not LLM. My middle name is Adam. It's a very, it's a very good name. Yeah. Ah, very cool. What's the best way? We've mentioned gleam.run multiple times. You mentioned that Discord, there's GitHub, there's sponsors, there's probably social media accounts. If people want to either dip their toe into the language

or into the community, what are the best touch points for folks? So if you go to gleam.run, in the very first part of the website on the homepage, there is a button that says Try Gleam. If you click on that, it will take you to an interactive tutorial that runs inside your browser. So it runs the compiler.

We've compiled the compiler to Wasm. It runs inside your browser and then we've got a series of interactive tutorials that will just take you through the entire language and you can blast through it in a few hours and get feedback without having to install Gleam or Erlang or anything like that. So you want to try it do that first and then join the discord um talk to people start making projects come say hi and and yeah and sponsor me there you

go in that order uh only uh maybe maybe sponsor me first and then check it out good one well gleam.run i love the dot runs jared this is such a cool url this is the first time i think i've seen a dot run definitely one that was that you remember i haven't remembered any other ones yeah so this is like my first one as well gleam.run it's cool you expect i actually had it in my browser history and i was coming back to you your stuff louis and i remember searching in my browser for Gleamlang or Gleamlang.org and I'm like, it's none of these. So I had to go to the Twitter

and be like, oh, Gleam.run. So it's not quite there in my memory bank but still cool. Oh, I think the.lang, or sorry, the dashlangs, not the.langs, the dashlangs are a thing of the past, you know? It's.run from here. It's a hack. Yeah, they're hacks, but a thing of the past, you know? It's dot run from here. It's a hack.

Yeah, they're hacks, but I'm used to them, you know? Yeah, for sure. Well, we need the dot lang TLD, gleam dot lang. That'd be sweet.

I really like it. Gleam dot run is the command for running a program. So not dot run, gleam run. It's just so perfect. Well, Louis, thank you

so much for sharing gleam with us and being so enthusiastic about open source and diving deep into GitHub sponsors and just sponsoring and perfect well louis thank you so much for sharing gleam with us and being so enthusiastic about open source and diving deep into github sponsors and just sponsoring and being so committed to letting the people who love your thing support you and even the enterprises like fly that support us as well support you in your endeavors and you know may the may the wind be at your back my friend thank you so much thank you so much. Thank you so much.

Thanks for having me, guys. It turns out that I'm his favorite, after all. Check this out. All right, so who's your favorite? Is it me or is it Jared? Oh, well, us Adams are going to stick together, right? That's right. Once he revealed his middle name was Adam,

I felt like he didn't have to stand a chance after that. Yeah. Well, I mean, I am named Adam. His middle name is Adam. So I guess I won. That's kind of funny. But a good next step is to go to gleam.run. Run, gleam, run.

Check it out and let us know what you think. Hop in Slack. Our community is free. changelog.com slash community. Hang your hat, call it home. You are welcome here. No imposters and it's totally free. Big thank you to our friends at Fire Hydrant,

our friends at Cloudflare, our friends at Image Proxy, and of course our friends and eating partners at Factor. And a massive, very big massive thank you to our friends and the home of changelog.com, fly.io

and Sentry, they got us covered. Use our code changelog to get $100 off the team plan. So cool. Sentry.io. And to the beat freak in residence, Breakmaster Cylinder, bring in those beats.

Do you like those new beats at the top of the show? Yeah, that's fresh. That's new. Hope you like it. And coming up this Friday on Changelog and Friends, Jared and i are talking to adam jacob about all things around the hashi corp open tofu debacle all the dust up of this cease and desist make sure you listen that's it this show's done we'll see you on friday Outro Music