Today we talk with Louis Pilfold, an ex-elixir/Lang developer.  Since 2018, Louis has been working on Gleam, and hesitantly admits to being its author.  This statically typed language that runs on Erlang virtual machine and draws its inspiration from several other languages.  With Gleam gaining a lot of traction, it’s definitely worth a look into this up and coming gem.

Hey everybody and welcome to another episode of Elixir Mix. This week on the panel we have Adi Aangar.

 

Hello.

 

Alan Weimar?

 

Hello.

 

And we have a special guest this week, and that is Louis Pilfold! Hello, Louis!

 

Hello, thanks for having me.

 

So we already had you on the show once to talk about Gleam, now we have you on the show again to talk about Gleam.

 

Ha ha ha

 

I see a pattern emerging. But yeah, might I tell you give your audience a quick round about who you are if they don't already do that and why we invited you again.

 

Well, I'm glad you invited me to talk about Gleam because I'm probably not that good at talking about the other things compared to Gleam. So I'm Louis Pilfold as you said. I've been an Elixir slash Leng developer for a long time. Roundabout Elixir version one is when I started to get really involved in it. And since 2018, I think. I've been working on a statically typed programming language that runs on the Erlang virtual machine. So we're trying to unify all the stuff that we love about Erlang and Elixir, you know, the runtime, the actors, the fault tolerance, all that great stuff. But also with the, the programming experience you get in ML languages like Elm and, and OCaml and to a lesser extent Haskell, you know, that, that thing of being helped as much as possible by the compiler, because I think that's a really fun way to program. And so now it's, it's It's resulted in this language, Gleam, which is dangerously usable now. You should check it out.

 

dangerously usable, I

 

Ha ha ha

 

love that.

 

One thing that I always find hilarious, Jose also when Elixir was new, he, because he's a humble guy like you, Louis, he would not say, hi I'm Jose Valim, creator of Elixir. He would try to fight like a round where yeah, I along with people have been working on this language. Eventually he just got used to it, like, okay, I'm the creator of Elixir, so I think you're gonna get there too. You're the creator of Glee.

 

I might get there one day, it still feels very weird. I very much understand that. Especially when people say, oh, you've done this amazing thing. And it's like, it's not, I've just spent a lot of time doing it. Like it's just time. Anyone can do it if they're stubborn enough, I think. I think that's the main thing you need to make a language.

 

Maybe stubbornness is a skill not everybody has.

 

Mm-hmm. 

 

But I actually remember, I think, it was a few years ago, like on the code beam in Stockholm, a few years ago you did gave a talk about, okay, hey, I have this idea, I have this project, I want to do that.

 

Uh

 

And

 

huh.

 

I think I even attended the talk, I'm not sure. But I do remember me thinking back then, yeah, let's see what comes

 

Hahaha

 

out of that. Giving a talk is easy, building a language is hard, you know?

 

Yeah, well, if you look at the, so it's kind of odd because the gleam GitHub repo is older than the languages. And so if you go to the very first commit, you find that it's a conference talk that I gave at Elixir London, which was called building your own Elixir or something like that, I think. And it was like, Hey, here's how you can compile. Here's how you make your own language. You compile it to beam bytecode. And that was really fun. I went, Oh, it's amazing. I had to do all these things. And, um, no, actually, what I actually did is I signed up to do the talk before it actually got it working. And then I had like a real panic as I tried to like, try and make both a language and the talk before the, before the deadline, just about managed to, just about managed to get it working. Went down pretty well, I think the talk and then I just ignored it. And then, but that like sowed the seed in my head of, Oh, maybe we could do something here. So, um, yeah, I think Galeen, you can probably squarely blame it on that one talk really.

 

We're very glad that we had the talk, I guess.

 

Hehehe

 

But yeah, I mean, you've been working on this for quite a while now. Like I said, we already had you in this show to talk about the basics. But something

 

Mm-hmm.

 

new, from what I understand, in the Gleemo sphere, let's call it that,

 

Hehehehehehe

 

has been getting OTP working inside of

 

Yeah.

 

Glee, right? And especially

 

Yeah.

 

like message passing and all those kind of things. So from what I understand, you kind of... You kinda have a working thing there now, is that true?

 

It is. And it kind of surprised me at least to be honest, because I don't know if you've heard this, but I feel like this was sort of a meme, like it's not possible to type OTP or you can't type messages or something like

 

I've heard

 

that.

 

that,

 

You always

 

yeah.

 

hear that. And I just took that for given when I started this project. Like I said, oh, I really want typed Erlang. People say, oh, you can't do this. And I go, oh, that's really disappointing. And I just felt really kind of depressed about the whole thing, really. And then after a while, I was like, actually, hold on. Most of the time when we're writing Erlang or Elixir, we're not actually doing OTP, we're just doing functional programming. And then there's

 

Hmm.

 

like five, 10% of replication, this is the actors and everything else just lives inside. Okay, so like I'll type 90% of the program and then we just do like unsafe casting when it's OTP time. I mean, that's not too dissimilar to what you get in, in like TypeScript and all these other gradual language at the moment. Okay, we'll just do that. And then over about two years of... you know, sort of early research and development. I sort of went, I kept having the, you know, when you're standing in the shower and things just strike you, it's like, oh, hold on, maybe, maybe this is possible. And that ended up, so I thinking around a bit now and yeah, as of pretty recently, well, for a while we've had something that works, but was sort of quite awkward and complicated, but with the most recent release of the gleam OTP library, I think we've got something that is, it works. Um, and is also like productive and practical and useful and quite nice to use. So that's that's pretty exciting.

 

So I guess how close are we then to having like a full application, everything written in Gleam now? I mean, because I... Before that it was, okay, if I want to delve into OTP, right, then I might have to dabble with Elixir or with Erlang or whatever. And now?

 

I think you can do it. I mean, there was a, there was a business that was almost entirely written in Gleam a couple of years ago, but that was, that was by Peter Saxon. And he, he's a wild card. He does everything early and everybody else.

 

Hahaha

 

Do you know when he made that HTTP two server? It's like, I'm just going to make my own. I don't need plug. Um, but now that, you know, now, now the rest of us are catching up with Peter and starting to do more things in Gleam. Like I've got a few little bits in, in production that are 100% Gleam. And that's quite fun. I guess that's not too weird because I made Gleam, but there's other people doing it as well. And there's one of the projects that I'm most exciting at the moment is there is a pure Gleam HTTP 1.1 server and they're currently working on HTTP 2 as well. It's partially inspired by Bandit, the Elixir one. Don't know if you've seen that, but it doesn't use any Erlang code other than a small, a little bit of Erlang glue inside their acceptable library. And... Um, according to our benchmarks, it is the fastest HTTP server in the entire railing world. It's much faster than cowboy. It's faster than bandit. It's faster than everything else. Like that to me, that says like, wow, this, this is actually usable now. And because it's a web server, it's all OTP and all that jazz.

 

How does that even work though? Because if I remember we did another podcast together for the rest station station, right? I will remember that a while back.

 

Hmm

 

Now that would actually help me understand a little bit more about how Gleam kind of works, at least the compiler, right? So unless something hasn't changed my understanding from what I remember a while back was that you write Gleam, you know, quote compile it, but it's actually transpiling it to actual Erlang

 

Mm-hmm.

 

code. So how could something that gets transpiled to Erlang somehow run faster than something written in Erlang? Is it because you guys are missing like a lot of, like the, the kind of like the nastiness of HTTP or, you

 

There's

 

know, I'm just trying to understand.

 

a few tiny things that would make, that possibly make Leam slightly faster. The main one would probably be, the two main ones probably be that with our labeled arguments, there's no runtime overhead because they're entirely resolved at compile time. So you don't have to like iterate lists and stuff. And we also don't use maps. We use records as like the most common, Elixir has structs, those are maps. We have custom types, those are records. So there's a tiny performance increase there, but like... Unless you're in a really hot loop, that's not going to make any difference. So the main, the main thing is that you can just think of Gleam as being the same speed as Erlang, the same way you can think of Elixir as being the same speed as Erlang, it's just that this HTTP server has it like a very slightly better design. Then, um, it has a very similar design to, to Bandit and a very similar design to, um, Ellie or Eli, I'm not sure how you pronounce that one, but it has a much better design than Cowboy. So it beats Cowboy just being, being better. I think the. The reason it's faster than Banda is that there is a slight performance bug in Elixir's URI module, which I think is going to be fixed soon. So when that happens, they will probably have almost exactly the same performance. Um, but the thing I find really cool about it, it's not that, Oh, it's faster because of Gleam, it's like you have enough power in Gleam now to make an OTP application, you know, you, you, you have enough flexibility to be able to make one that can compete with the best ones that already exist today.

 

So what was your journey then? We are actually at a point where you said it's dangerously usable.

 

Ha

 

What

 

ha. Ha ha ha.

 

was the journey there? You said that you had some sorrowful thoughts, especially about the OTP

 

Mm-hmm.

 

library. Were there some points in time where you ran into dead ends? I do remember seeing some discussions on... column type. I'm very bad with type system theory, so I probably botched that. But I do remember there being a lot of discussion about how specific things can be working in the Gleam Discord, and I would be interested in seeing what was your thought process, right? What were the things where you're like, okay, this might work. Oh, no, it doesn't. But then maybe you took some learning away from that. So maybe lead us a bit through the story there.

 

Yes. I think the first thing people normally try to do when they want to apply types to OTP and Erlang is that they take GenServer and they try and make a wrapper around it that's type safe. And if you look at Elixir, they're not doing it for types, but they've done the same sort of thing. They take Erlang's GenServer and they've made the Elixir GenServer as like a macro layer on top of it that adds no runtime overhead and just gives you a nicer API. That's cool. We could try and do the same thing, like adapt the API to our needs. But, um, and you know, and you can kind of make something work ish, but it's not super amazing and I found it after using it for a while, I found it quite unfulfilling because just cause you've got something that is expressive enough to be able to do that, it doesn't actually mean you can really do the same things that you can do inside a language. Um, what you really want to be able to do in order to prove that you've got the correct abstraction, I think is you want to be able to start from nothing and build it up to OTP. Because OTP isn't written, OTP doesn't come with the beam. You know, it's not written in C, it's written in Erlang. You get like send, receive, link, monitor, trap exits, anything else that might be, there might be one or two more concurrency primitives, but Erlang has those tiny little C functions than everything else you can build up in Erlang. So at some point in this genuine, actually we really wanna find like the smallest amount of, core code, you know, these primitives, which if we were, if we were directly on the virtual machine, it would be written in C, but we're not, we're one layer up. It can be written in Erlang, and those functions pretty much just call the C versions. If we can find the right type extraction for those, we can build up. And we've now done that to such a fashion where we've got the same primitives and we can start implement, we can start working out what the, or rather, we have the same primitives. with slightly different APIs. And then it was a matter of working out which API system solve it. So we don't have Jen server, but we've got something that is equivalent. Does the same job, has the same power, but has a different API in order to make it type safe. And the nice thing about having the same primitives is that you can just look at the implementation of the, the ones in Erlang, like, okay, well, how does, how does Jen server work? Oh, it's this message. It's this message loop, um, mixed with, uh, proc libs, um, starting process and the Jen modules. like sending and replying thing. Cool, I can just convert those things over to Gleam and I've got basically the same thing. And it's really quite interesting looking inside, it's really quite interesting to look inside OTP because like it's all Erlang code, like it's all there. Like it sort of seems magic, but like it's not actually that complicated when you look inside it and all the little hairy bits have comments on them mostly so you can sort of figure out what's going on there. And... I kept finding problems when I was building this and discovering that they had already found them and they've solved it in a different way. So a good example of this will be... attaching semantic information to messages. And for me, I mean types, you know, what I

 

Hmm.

 

want to be able to send, I have a process, it has a protocol, it says I accept this kind of message and this kind of message, this kind of message, right? So I want to attach type information to that. So I've got some semantic meaning I want to attach to, like a reference to a process. How on earth do I do that? That's really tricky. But if you look inside OTP, they have the same problem. It's not about types, but like it's still static semantic information being attached to messages in your inbox. And this case it is replies. If I've sent a message to a process and I'm expecting to get a reply and I've got 10 messages in my inbox, how do I know which one of those is the one that it has the right semantics for, for what I'm trying to do? And the way they do it is with, I have a little, you know, in gen server, you've got a from, you know, you get the message, the from and the states. The from is a tuple with a reference and the actual, no, a reference and the PID. Well, that's just a way of correlating, that little, that's just a tag that correlates with semantic information of the process. So what if we don't use that for just replying? What if we use that all of the time? And now you've got a thing to tie your type information to. So we basically just took a pre-existing, abstraction inside ATP and just sort of. spread it around a little bit more and suddenly we could build the whole of OTP. I thought that was really cool and it makes me feel a lot more confident the fact that we're not inventing things from scratch like there's a lot of precedence for all of the abstractions we've pulled out of this.

 

That makes

 

That

 

a

 

was

 

lot

 

quite

 

of

 

a

 

sense.

 

ramble.

 

No, but I was trying to get it to ramble. So mission accomplished.

 

Oh

 

That makes a lot of sense. It's also kind of interesting. It reminds me of the little Elixir and OTP guidebook where you also kind of build

 

Hmm.

 

OTP from scratch, at least to a certain degree, to demystify some of that. So it's

 

it's

 

interesting to see how OTP stands the test of time here.

 

It's really fun. Like maybe don't do it in production or maybe do if you're Peter, but, um, like re-implement some OTP things or like, you know, just, just make your own special processes. Um, yeah, just, just, just see what you can do with send and receive and spawn. You can go quite a long way.

 

I have a question, maybe

 

Thank you.

 

let me phrase it differently. So how, what we say are still some foot guns or some things where you

 

Hmm.

 

say, okay, this is not as yet working as we want it to be working. I

 

Mm.

 

mean, one thing which pops to my mind, what I wanted to ask is like clustering and then having

 

Yeah.

 

multiple different versions of the app. That sounds like, that sounds messy.

 

Yeah. Yeah. That was another one where I'm like, oh, that's just not possible. That's out of scope. You know, you just, you do it the Erlang way and you just connect it and don't mess up. Like that's the strategy here. Don't make a mistake and you'll be fine. Um, but I do actually think after chat with Jose, actually, um, I think this was his idea that you could actually do full type checking of rel, of, um, you could do full type checking of joining a cluster or of upgrading a cluster. If you annotated the clusters with all of the type information of the program that they're running, and then any new node that joins has the same information. And then if you have some kind of, it doesn't have to be a full inference algorithm for the types, but just a unification algorithm. So you take the type manifest from the cluster, you type the type manifest from the node that's joining, you put them together, and then you just unify all the functions to make sure that they line up. If you do that, you could have completely safe upgrades. And that would probably make, you know, because you've got to do a lot of work to be confident that your upgrade's going to perform as it should. You could actually probably, if you implemented that, make it easier to use upgrades than it currently is, which I think is really quite exciting. It's something I haven't even started trying to do because, yeah, I've got a whole language to work on and I don't use, yeah, I don't deploy like that. So it's not very useful for me, but. It's a problem you could solve in the same way. Yeah, it's tricky. Distributing computing is something we'd love to solve with types, but there's only so many battles that I can take on. I'm hoping that if I say this on enough podcasts, somebody else will do it.

 

Hint hint.

 

So yeah, steal that idea. Message me or maybe Jose if you want some further thoughts.

 

I also think, my personal opinion is that some of these discussions about clustering, about hotcode upgrades, get more coverage than what they're worth, to be honest.

 

Yeah.

 

Because I mean, yeah, hotcode upgrades are cool. I agree, but

 

Mm-hmm.

 

I have never used them

 

Yeah,

 

in

 

it's

 

production.

 

like, it's amazing we can do that. Like if you have one computer that lives up a telegraph pole in

 

Yeah.

 

a remote

 

Yeah.

 

village somewhere, you can do upgrades. But like, I've run mine inside a data center. I've got surplus computers. I can just turn them off and on again. That's fine.

 

Yeah, I guess that's the reality for most people. So

 

Yeah.

 

even if you, for example, would say, hey, this is just something we don't aim to support in GLEAM, at least not in the near future, I think that's a very valid trade-off to make.

 

But I mean, that was also the story for OTP. And it's quite exciting that we've done, oh, actually, no, we can do it. So maybe, maybe one of those things where, um, you know, someone has a spare few months and just scratches the niche and suddenly we have this awesome thing. And if we can think of a, um, a working group formed for, what was it? Um, type interrupt between the different languages. And I don't think there's been much activity in it later, but you could imagine if, if that becomes a little more mature and we have a, we have a. standard way of expressing types between all the different languages. And then somebody starts working on this. It could be very much like the, the, um, I forget, I forget which proposal it was, but the proposal, the unified documentation across all of the beam languages. So now you can see Erlang docs and Elixir docs and Erlang and all that stuff. You know, we could have the same thing, but for type manifests of your cluster. And then with the WhatsApp type checker for Erlang and the, you know, the, the, um, set theoretic types for Elixir if those things will land and Gleam's just being Gleam. You know, suddenly we can start sharing all these, all these manifests with each other and then we can use them for doing hot code upgrades and all this great stuff. So we are kind of building all the pieces. It's getting easier to do this all the time. We just haven't got to the end yet.

 

I'm still kind of surprised that people just cannot read the type spec information at runtime and kind of use that for type checking. Because it seems like it's only for dialyzer and documentation.

 

Yeah, I mean, it's tricky. Like there's a mix of, there's lots of people who don't, who write, I'm one of these actually, lots of people who write the annotations and then don't use dialyzer because I personally find it a bit unfulfilling

 

Me too.

 

of a tool. Like

 

Me

 

I

 

too.

 

don't find it particularly useful. Like it's quite slow and I find the error message is really confusing. So I just go, oh, I'm not finding this useful. I just, you know, this is a dynamic language, I'll do that. And so there's loads of packages that are wrong, probably written by me. You know, I think that it's this, but it's actually something else and I've never verified it. But even when you do use dialyzer, I think there's lots of situations in which, um, other type systems or other type checkers wouldn't allow it or say it was incorrect, but dialyzer will, I think. So I think the philosophy of dialyzer is, um, no false negatives. Is that right?

 

Yeah,

 

So.

 

it's success typing. It's success

 

Yeah.

 

typing.

 

So, you know, in, in Gleam, if we can't tell it's correct, you're not allowed to do it. Like it has to be correct. And if that, if, if your program crashes and you've not explicitly said it's going to crash, that's a bug as far as I'm concerned. Um, and I'm going to do something about it because I want to restrict the, the program space as much as possible into like a really nice cozy little box where you can't really move much. That sounds quite unpleasant, but like, um, it's a very comfortable box and it's very easy to get the stuff done. You want to do well, dialyzer, you know, they want to make sure that there really is a problem before doing something. So if it complains you. probably really should fix it, but that means that this whole space where things can go wrong and dialyzing, you can't be sure about it. So how useful are the type annotations for things like, um, making sure that your, your upgrades are going to work. Maybe not very like it might be right in the optimal case, but I want to have much more certainty with that.

 

Yeah,

 

Yeah, but,

 

for

 

but

 

my

 

even

 

personal...

 

if sorry, but I'm still kind of stuck on this. Like, let's just like, why can't we have a way that we could just read that and say, okay, whatever I know that dialyser wants to actually prove that what you say is true, right.

 

Mm-hmm.

 

But why can't we just say, okay, let's just accept that the type spec is true. And then somehow write some kind of type checking at compile time that says, okay, all this stuff. And then once we try to look for, like, try to do like a case statement, something that we don't have a match. we can just crap out and say, hey, this is wrong. That's the

 

I

 

part

 

think,

 

I

 

I mean...

 

can never really understand, why we can never do that.

 

I think you could use the same type annotations and then, you know, there's a few different ways you can use them. You know, you can, there's the problem of trying to work out if your type annotations are actually correct for the individual implementations inside your functions, which is, you know, what Dialyzer tries to do. And there's no reason you couldn't keep that same interface of, you know, the type specs and then just write a different inference algorithm on top of that. So I think that's what the WhatsApp team are doing with the new type checker. with a name that I can never remember. I don't think they've extended the syntax in any way. They've just used the existing one and then just given a lot more power to it, which is great because it means all of these libraries that have type annotations already, they can already use those. And it will just be sort of a value add over dialyzer, hopefully. The other way

 

The

 

you could

 

other way

 

use it

 

to

 

is

 

use it is

 

you just

 

you

 

ignore

 

just ignore

 

all of the

 

all

 

implementation

 

of the implementation.

 

and you just say, these type annotations are correct. And then... You can't use it for sort of type checking in development as you would do normally, but you could use it for things like this upgrading system as I've suggested. It's like so long as every function has an annotation, you could make sure that those annotations line up with whatever the cluster thinks those functions should have. Like that could also be useful. I think this kind of highlights the fact that when we talk about types, we're not really talking about one thing. It's really easy to say, you know, Gleam is Erlang with types or Elixir is going to get types or Erlang is going to get types, but you know, it's kind of like, you know, we don't talk about dynamic types in that way. You know, we don't say, oh, it's going to be a dynamic type of language. We all know that PHP and JavaScript and Elixir and Erlang are all dynamically typed, but they've all got a radically different feel to them. And like the implications of using that, that runtime type system is quite different. So, you know, you can... If you like dialyzer, you could argue that Erlang is already a statically typed language. And, you know, if you look at languages like C and Go, which are statically typed, but they're not as... I'm not sure what the

 

rigorous.

 

word is, but yeah, you know, exactly that sort of thing. You know, there's lots of ways in which you could make mistakes. And that would be fine because that's the trade-off they want, and that's the experience they want for the language. They can do other things as a result. But if I were saying Gleam is a strongly typed language, I would feel quite unsatisfied if it had the same experience as, Dialyzer Erlang or C for example. So it's kind of many beasts really. There are useful things you can do with it, but it just comes down to what exactly do you mean by types and what do you expect from that?

 

There's also a pretty good article from... I don't know... Ovid? Where he says, like, what to know before debating type systems. That's basically

 

I'm gonna

 

the

 

go.

 

title. It goes into some of the details you just laid out. Like, when people say type systems, there's like a whole bunch of different assumptions baked in, usually. Especially in some of the discussions, people say, like, oh, static type systems are shit, and then they think of Java.

 

Yeah.

 

That's their

 

Yeah.

 

whole experience with static type systems. So it's not an easy answer to like also the question static type systems, dynamic type systems, what is better, what is not blah, blah, blah, blah. It's a complex situation to be in. And I would like to also add one note earlier, like, as you said, like a different influence argument from, from, from, from, from, from, from, from dialyzer, there's actually a project a while ago, which started, but I think it's, it's dead now. that was called Gradualizer, where

 

Mm-hmm.

 

they basically did exactly that. They took the

 

Yeah.

 

same type annotations as Dialyzer does, but then says, okay, now we actually need to match. They need to be true, not like Dialyzer. I think that what Dialyzer basically does is like, if one path for your program can resolve in the right type, Dialyzer is going to be like, yeah, okay, it's good.

 

I do.

 

And it's also going to, it also stops interfering at some point. It complexity gets too high because

 

Yeah.

 

When you can see, when you can think whether it is originally came from, like as this thing added on top of a language would at that point didn't have any kind of type checking, at least not at an aesthetically typed manner, then yeah, makes sense. Like you don't want to have to rewrite your whole code base just because you run this thing over it. But in day to day work, if like if you're a Greenfield project, some more rigor could sometimes be nice. I definitely have. My experience with Dialyzer so far has been that it's been more hassle than it's worth. Like

 

Mm-hmm.

 

every kind of error I found with Dialyzer was always, ah okay,

 

Thank you.

 

I

 

Bye.

 

mistyped the type annotation here, which is, has some value, but I've never actually found a bug with it. Like

 

Hmm.

 

that hasn't happened yet. And then when

 

I found

 

you also,

 

one.

 

oh

 

I

 

wow,

 

found

 

okay.

 

one bug. It wasn't in my code though. It was in OTP. It's

 

and OTB.

 

like some, some rarely used function like deep, deep, deep down. Um, has a slightly incorrect type annotation in a way that makes no difference whatsoever. So like it's fine, but it caused like, uh, like an entire terminal size error message that made no sense to me. And it took me

 

Yeah,

 

like

 

yeah.

 

three days of digging to try and work out where it was coming from.

 

And that is exactly what I also found. I found wrong type annotations. But I never found wrong code.

 

Yeah, yeah, exactly.

 

So, nah. And also, I mean, I'm not sure if any of you has ever had the pleasure of setting up dialyzer in a CI system without your CI build times blowing up ridiculously, then you get into caching.

 

Yeah.

 

That's no bueno. So... I think there's definitely room for better tooling here. And I would be very interested because a while ago there was a bit of a discussion, I think it was on ElixirConf, where Jose kind of opened up this can of worms and said like maybe types in Elixir are possible. There was like a discussion on that. I'm not sure if you have an opinion on that, Louis. Care to share anything you think about that?

 

Well, I'm a type zealot, so yeah, they should do it. They should force everyone to use it. No. I think the idea of being like yes types or no types is kind of silly. I think it's just about adding more tools that you can use. It's

 

Yeah,

 

like

 

yeah.

 

the formatter. If you don't like it, just don't use it. It's fine. What's the problem? And the experience they get with the spirit. Josie is clever. The core team is really clever. they understand that they need to be able to apply this to a language, to the language in a way that isn't gonna be destructive. That isn't gonna be, you know, isn't gonna ruin the day for all of their many existing users. So they're gonna find something that's really non-intrusive and you can retroactively apply to code bases. And I'm sure it's gonna be absolutely amazing like everything else they've made. Gleam does not do that. If you had a massive code base and you wanted to add Gleam type system to that, it would be absolute hell. So... Yeah, don't do that. I mean, you can't do that. There's no way for you to turn it off. You're doing it. So like the two experiences are gonna be so different. I'm not even sure you could really compare them in the same way. And that's great. I wanna see more types on the beam because I think they're genuinely useful. And I actually say, people talk about me with types because I've made this type thing, but I actually just really love static analysis. Like that's the real winner. And I don't really care. Before I was writing type checker, I was writing linters. Like I wrote the first version or I wrote the project that credo was a fork of. For example, I wrote the, I wrote, yeah.

 

Dogma? What's a dogma?

 

Yeah. Dog man. That's the one, you know, so I just, I love static analysis. I love the idea that you can just look at a program and not do any work and go. That's wrong. That can be changed. Like this could be improved. Like that's so useful. I want, I have this really powerful computer in front of me. I want to use it for more than just typing text and checking Slack and email. I really want it to help me with my job. And I think static analysis is a really powerful way to do it. So yeah, I think they're going to do great. And I hope that they succeed. I also know they're really clever in the way that they keep, you know, this might not ever happen. Like every time they talk about it, like, this is just a research project. We may never land. We're just, we'll see what happens.

 

Yeah, yeah.

 

Very clever.

 

Yeah,

 

I mean, look at the

 

you

 

odds.

 

just mentioned, sorry, you just mentioned about like, the WhatsApp team working on types, didn't they already have something and they, they junked it. So this is like their second attempt doing types or they just picked up the old one.

 

Yeah, I'm not sure what's, I don't, I'm not privy to anything that's internal. WhatsApp. I used to have a few people who would like mess me up. Guess what's happening. This is exciting, but they've stopped talking to me now. So I guess they've left WhatsApp or something, but, um, yeah, my impression was that they started a project, announced it, and then quietly stopped it. And I'm not really sure why. And they then after a little while released it as open source. And I was quite surprised because it seemed to be written in Scala, which I didn't see coming, but there you go. But they just announced the new one, didn't they? They've also released the source at the time they announced it and Excuse me, but it's also released. It's sorry. It's also written in Scala, which makes me think it probably is a direct descendant of it, but It has a different name. So I don't really, I've not read the, I've not properly read the source code through them. So I don't really know if they have different approaches or Um, it takes the same approach and it's just evolved a lot, or maybe it's made by different teams, I don't know, but it's, it's got a different name. So they feel it's different. I.

 

So there is a project called Equalizer. With like,

 

That, yeah, that

 

is

 

one.

 

that the new one or is that the old one?

 

That's the new one, I think. And great team, you know, I know some lovely people, but come on guys, pick a better name. I don't know how to pronounce it at all.

 

Yeah, yeah, yeah, yeah, I think it's WhatsApp because that's W-A, that's why

 

Yeah.

 

equalizer. It's written 55% in our lang, 35% in Scala and 9.2% in Rust. That's a wild mix.

 

Isn't it weird? And

 

That's

 

the,

 

a wild

 

the,

 

mix.

 

the Scala is compiled to native using the GraalVM. So it doesn't use the JVM. It's a, it's a really interesting looking project.

 

The static type one is like, uh, ERLT.

 

Mm-hmm.

 

That's an early prototype of like an experimental early dialogue with first class support for static typing, but the last update was 16 months ago. And I guess that's like, that's the project which, which kind of got abandoned and you're thinking

 

Mm-hmm.

 

of Alan. So

 

Yeah.

 

I'm going to

 

What

 

link

 

is

 

all of

 

the,

 

that in the show notes, by the way, if somebody wants to check it out.

 

why use Scala? I'm so curious. I mean, obviously, Rust, we all know is, it's Rust, right? But

 

Yeah.

 

Scala, I mean, is it, I mean, it seems like they wrote this CLI in it. Is it good with CLIs or what's the story? Do you have any idea?

 

I don't know. I was really surprised because I thought there was two ways it could go. It would either be Erlang because you write the Erlang thing in Erlang, right? That makes sense to me. But I thought the other way it could go is OCaml because I know that Facebook has a big OCaml team and a lot of it is to do with static analysis. So do you remember Flow? You know, it was like the TypeScript alternative that was written in OCaml and their... Python type checker, I think is also written in OCaml. So I was like, oh, it's going to be another OCaml thing. It's probably going to use the same, I don't know, core libraries or something as ever once. Then it popped up in its scalars. Oh, I've absolutely no idea what's going on. Very cool though. If, you know, we can be in a world where both the big daddy languages on the beam have type checking, that'd be awesome. And I'll be like, oh, maybe I influenced that a little bit. Just sort of being the gun on it. Yeah, we can do it.

 

I'm definitely

 

I'll take it.

 

interested to see how we go from here also, like with types on the beam. I definitely feel like Gleam is the project which popularized and mainstreamed, at least in our niche, this

 

Mm-hmm.

 

discussion more. It has definitely created some waves. And I'm not, for example, I'm not sure if this whole discussion about types in Elixir would have been happening if not for Gleam.

 

I don't know how you'd measure that. I don't know if it's true, but I really, I kind of hope it is. It's a lovely fit. Like, so Gleam sort of started with me trying to scratch my own itch. And, you know, it's been super satisfying to make this thing that I actually think is really good. And the fact other people are using it as well, that's awesome. And having fun of it. It may be that we never get to the point where, you know, it has the same traction that Elixir and Erlang has, where there's loads of businesses running it. Like, I think we're well on the path to getting there, but... If it all falls apart at some point and we don't get there, like it still would have been super satisfying. But if we can just have a sort of knock on effect of, you know, that thing I said earlier of like, oh, you can't type OTP, you can't type Erlang, if we can just dismiss that idea and get other, um, portions of the wider communities to start experimenting with, with types and, and, you know, apply it to these other, these other parts of the ecosystem. That's such a huge amount of value that's come out of there. And that's, that's awesome. That'd be such a huge success, I think, if I've contributed to that in some fashion.

 

Yeah, do you know of any like what's the current status with the elixir type checking or just you just know as much as we know, which is just say announced it.

 

Yeah, I haven't, the last time I was properly talking to them was when they were doing the previous round of type checking when they started building a bunch of stuff of guards. So, you know, if you use a struct incorrectly, it tells you you're missing a field or something like that. But I sort of got the impression that that project had finished and, you know, no one was inviting me to any secret type talks anymore. Talks, like little discussion things. Yeah, and then this thing came out, I was like, oh, well, that sounds really cool. I'm really interested to see what comes from it because I don't really know what a set theoretic type is either, so it seems very fresh. Yeah, so I can only speculate.

 

You didn't go home and open up your type book because I think you recommended a type book last time you're around or something. You said it was for

 

Yeah,

 

the

 

I think

 

little

 

it's like,

 

book

 

I think

 

of

 

it's

 

types

 

like,

 

or something.

 

I think it's super new. Isn't the guy they're working with the person who invented it. I need to go read his thesis or something. Um, it's super fresh. No, no, no, none of my old books have it. Gleam's type technologies are all like 1980s, 1990s kind of stuff, which I, I think, you know, good and proven, but, um, good and proven for particular kind of language, which is not Elixir. So I used to feel a bit, um, you know, people say, Oh, well, you know, why'd you need Gleam if- Elixir is going to get typed. So why doesn't, why doesn't it just like type Elixir or type Erlang? And then you don't need to do this whole language bit. And that was a really hard question to ask at first, but I think the longer I've been doing this, the more it's become clear to me that, you know, typed to many different things, you know, this is a very broad term and what is good for Elixir and what's good for Erlang is not good for, you know, this thing that I've now created, like the experience, even when they've got finished this, even if they're wildly successful and they've got, um, all the typing they could ever want. It's still gonna be a very different experience, I think, in Elixir and Erlang in Gleam. For example, I believe the Erlang folks are not planning to have exhaustiveness checking. That being, so if you've got a type that is a union of, oh, for example, a result tuple, it could be okay data, it could be error, reason. If you forget to pattern match on one of those things, like... You probably wouldn't because it's only got two, but you know, if you had, if you had a similar one that has many more variants, um, and you forgot to pattern match in one of them. I think the plan is for the other language not to tell you because that's not something they intend to support in their type system because of whatever constraints or whatever experience they want to get. In Gleam, we would consider that to be like a huge problem. Like we really want you to know

 

Hmm.

 

about all the different variants and all the different paths for your code. So, you know, you, there's a trade off there. and it will result in a hugely different experience. So like, yeah, I think even if we get everything to be super typed, there's still really good reasons to pick like elixir over Erlang or Erlang over elixir or Gleam over elixir or, you know, whichever one you fancy.

 

Yeah, I love the exhaustive checking like I hated it when I ran into Elm.

 

Hehehe

 

But after getting used to it, I was like, this is really awesome. And then

 

Yeah.

 

Russ does it. And yeah, I just feel like if you don't do it, yeah, I don't know what's, what's wrong with you. It's

 

Yeah,

 

awesome. Awesome idea.

 

it is definitely one of those things where like, it just, like you start using one of these languages and it just beats you. You know, it just feels horrible. It's like, Oh, I just want to do, let me compile my code and run. It's like, no, it's not good enough yet. Very, very depressing. And after all, you're like, Oh, actually, no, I see what you're, see what you're on about now. This is pretty good. Isn't it?

 

Isn't

 

It's

 

that

 

kind

 

Yep.

 

of,

 

a form of Stockholm syndrome or something?

 

yeah, it's like, you know, I, this beating is the only way I know how to get, get to sleep at night anymore. Um, but it's it. I can't, it's one of these things where like, I recommend everyone learn it, but I reckon, I also acknowledge that it's probably going to ruin a lot of other languages for you, you know, because every time, every time I'm using a language doesn't have my, oh man, I really wish I had this thing.

 

I think it's interesting, Elm also was the language where I first came into contact with that and I immediately loved it. I was like, oh, this is great. And now when I change it and it tells me I missed it over here,

 

Yeah.

 

for a short while I had this mad idea of building my own portfolio website with Elm. I ditched it after a while.

 

Hehehehe

 

But that was just so amazing. When I added a new and it immediately told me, okay, over there and there and

 

Yeah.

 

there, that's where you need to change things now. That was just, that was a pleasure.

 

I think you just got to know. So I think, I think the biggest impact that these really strong type systems have is it changes the way that you write code, you know, like, so when, when I'm doing electric and Erlang and, or JavaScript or, you know, Ruby or whatever, I would, I always find that I, um, sort of trying how am I going to express as a metaphor is going to be very strange, but, uh, you know, I start from the start point and I want to go over here and I just sort of like dig directly towards that thing. And then I've just got the go from the beginning to success as quickly as possible, and then I sort of like slowly expand out and fill out all of the edge cases and error, error handling, all that stuff that I didn't need to do. Because I want to get to that point where I can start doing that first, like end to end test, or it would be like unit test or integration test or rep or something like that. You just can't do that really with, um, you know, strong static type system. And if you try and apply that, that tech, the earlier technique. or any other technique, which is, you know, super productive in those languages and trying to do it this way. It feels bad. And like, I can really understand why people say, Oh, I don't like types because it just takes away a whole bunch of familiar tools, but it gives you some other ones, like you've got to, you've got to take the time to learn this thing, as you said, like, Oh, I just make a little change and it says, here, here, here, here. Like, Oh, actually that's a really nice workflow. You know, if you, if you think of your workflow as like stating what kind of change you want to make, and then the computer goes, okay, here's how you do it. That's super nice. But yeah, you gotta be willing to do something a bit different.

 

So we kind of went on tangent here. So I have one last question I would like to bring us back onto the Gleam topic. And that is,

 

Oh, yeah.

 

I mean, you know, I said, okay, you kind of take up this whole LTP thing. And the first, in the beginning, everybody said like, oh, it can't be done. And you also said, okay, there might be other things, but is there anything else concrete in the works right now where you say, okay, this is something we're working on in Gleam, something we want to get better at? I do know that like, for example, the tooling has become a lot better in

 

Mm-hmm.

 

the recent months. So anything else exciting to share? I think the language service also thing you're working on.

 

Yeah.

 

So.

 

So there's a few additions to the language that we really want. So we've got exhaustiveness checking, but it's kind of, it's not, it's not complete basically, like it will, it will, um, basically it just won't always tell you if you're, if your thing is not exhaustive because it turns out it was often exhaustiveness checking is a really hard problem in computer science. And so, yeah, you've got to sit down and read a lot of papers and work at how to implement it optimally. And we've. I think we've like zeroed in on an algorithm we want to use and, you know, we, we have done all the research and we've got a lot of things, but we just need to, somebody, probably me needs to sit down and spend like a month or two working on that thing. Um, so when we have that, that'd be really awesome. That'd be like one of the biggest things done. Um,

 

Hmm?

 

other than that, I really want to have, uh, optional arguments is something that we've been planned for a long time, but haven't done it. string interpolation, that sounds really dull, but that's a really nice quality of life thing that we don't have. Just a couple little things like that in Core Language. But the main work is probably gonna be outside of the language, so that's kinda cool. The Core Language is pretty much there. The main work is gonna be in tooling. And so we built a language server protocol, language server protocol server, a language server this year. And that's been really awesome because now we're starting to get all these IDE features inside, you know, inside every editor you could ever want. But it's really highlighting that the, the architecture of the compiler is not designed for a language server. It's designed for just straight up compilation. And it's we've stretched what we've got in order to fit with that, but really to make a really good language server, we need to change a bunch of things inside the compiler. So if you're compiling source code to run, you only really care if it succeeds or fails. You know, if it doesn't pass, okay, I just stop. I don't need to do anything more. Oh, if this function doesn't type check, okay, I'll just stop. I don't need to do the rest. But if the whole point is that you're continuously passing and type checking and learning things about the code while someone's editing it, the majority of the time it's gonna be wrong, right? So we want you to be able to type check 98% of your program. and still tell you things about it. That's really annoying. I now need to change all of these algorithms that like succeed

 

Hehehehe

 

or fail to mostly succeed and still gather useful information about it. And it's something where, and I've built a load of clever things into the code to like make sure that it definitely succeeds or fails. And now they are less than worthless. They actively hinder me. So I need to restructure a bunch of stuff. It's a shame. It's one of these things where If I had realized that we needed to do this at the beginning, it would be a bunch less work for us now, but not, not quite as much work in the run up, which is a real shame, but it's not, it's not a huge, and the compiler is actually quite easy to refactor, so we'll get there. It just means there's going to be a period of, um, less user facing features than you might see otherwise. But that's okay because I'm actually ramping up the number of hours I'm doing on Gleam, so you'll see about the same number of things go through the pipeline. But. There'll also be really dull things like I've changed the metadata serialization format, I've changed the, this to do that, et cetera. Um, so that's going to, that's going to be really cool. And once we have this incremental, you know, very incremental compiler, the language server and the tooling will be able to do so much more. And I think we could get an experience close to, um, like what you get in some Java, Java IDEs and, and Rust with Rust analyzing stuff, like really, really nice tooling. And because it's actually a core constraint, a core concern of the, you know, the language team, like me and whoever's decides on to help out, we can reuse the whole compiler. And I think we can make a language server much faster than a lot of other ecosystems can, and it will be capable of doing a lot more than a lot of other ecosystems can do because we have the full power of everything that the compiler can do rather than what a language server is, it tends to be in other ecosystems, they just have to implement. the own version of the front end of the compiler

 

Eh.

 

from scratch. That hurts. That's a lot of work, but well, we've already made that, you know, we just need to be using it. I need to change the shape of it now, but that's okay. We can do that. We're still going to get, we're still going to move faster overall than, um, making a whole new one.

 

And I think that that's definitely like, I can already see how that work contributes then to what the ease of use for language, right? Because I mean, I just know for a fact if you like have slow response from from editor, I think everybody of us knows that like, this is just painful, right?

 

Yeah.

 

Like, just tell me what's wrong already.

 

Hehehe

 

Don't annoy me with errors from the language server or whatever from the extension. Just just be like, this is like something where you really only appreciate. a good integration when you see the

 

Yeah.

 

bad one basically.

 

Yeah. I think, I think it's kind of a saving grace. The fact that everyone, most of the ecosystems are, you know, there's somebody who has decided to make a language server and they're an absolute hero and they have, you know, built this thing from scratch. And they've done a great job, but like, it still actually doesn't do very much. If you compare it to like some of the really amazing ones that are either huge companies or there's just a, you know, the genius at the wheel. Like the Rust analyzer language server is absolutely incredible. Or like the You know, all the stuff that comes out of jet brains, like that's all amazing.

 

Mm.

 

But most of them kind of rubbish, like, you know, not to disrespect any of the people who work on ones for, you know, other languages, like, I don't know. I don't know. Like the, I don't know which one to pick because I don't want to be rude to anyone, but

 

I'm

 

like.

 

gonna take it off your hands and say, I'm very grateful that we have an Elixir language server, but it keeps crashing on me. Ha ha ha ha.

 

But it's just such a hard thing to make. And I think as a result, we've all got expectations that are not super high. Like the little that they can give you is so useful and so valuable, but I know we can do so much better. And I'm really excited about what we're gonna be able to do once we've got the compiler into shape. It's gonna be super cool. Super, super, super cool. Like... click on a type and generate things from it. It's going to be so nice.

 

nice i'm kind of itching i still have this like a few weeks ago adi and me spoke about um side projects also and i still have this one idea i really want to build out because it's also scratching an edge of mine now i'm kind of tempted i was always i was planning to do it in elixir but huh maybe maybe

 

Hey!

 

maybe i might be using gleam Okay, Adi, Alan, do you have any questions you'd like to ask before we kind of transition to pics? Because we're nearing the one hour mark.

 

I just have some praise like great job for kind of keep this thing forward. I mean, I don't know if I can keep so focused on something and anything. So I'm happy that you are keep moving on this one. Especially because I keep hearing Oh, yeah, I did this I did that I made a new language. It's like you make a new language all the time. But Gleaves are running and it's doing better

 

Mm-hmm.

 

and better every time you know we talk about it.

 

Thank you. Yeah. I think, I think one of the saving graces is now so big that there are multiple different things I can work on. Like I work on tooling for a bit and I get it working like, oh God, I'm really tired of tooling. Okay. Well I'm going to work in the type checker. Oh God, I'm really tired of typing. Oh, I'm going to work on OTP. So like it has branched out a bit, but yeah, being, being stubborn at the beginning really helps, but thank you.

 

Or maybe sorry, I actually do have one question. Do you mind to talk a little bit about your sponsors? Because I think it's good to kind of get them out there since responding in some kind of way, right?

 

Mm-hmm. Yeah, so Gleam is financed by people very kindly sponsoring on GitHub sponsors. So if you like Gleam, you should just hop on GitHub and, you know, give me a dollar and buy me a coffee and stuff. But we've got two corporate sponsors who have been absolutely amazing. And they are, I don't know, probably the majority of the money comes from those guys. And they are what they are the guys who make it possible for me to be. I do. you know, spend most of my time working with Gleam, which is really exciting. And if we get more people doing that, we can go, I can go full time and it's just going to get faster and faster. So it's like, you know, super, super huge. Thank you to fly.io and Alembic for, for their excellent support.

 

Yeah, we definitely should support Louis because I think Arie and me are both supporting. So all listeners are now basically obligated to also support.

 

Join the cool Gleam gang,

 

Yeah,

 

yeah.

 

to join the cool club. Okay. Are there anything from you?

 

No, I just want to apologize my my CEO and a couple of board members just woke up in the Pacific time and with like a Bunch of crazy questions and I've been like every time I want to bring up a tangent. I've been distracted. I'm so sorry I feel terrible. But yeah again, just want to thank Louie again for all the work and we are

 

Definitely.

 

I'm gonna say we're about a couple months away

 

Mm-hmm.

 

from using gleam and production at

 

Wow.

 

my company Yeah, we have a couple really good candidates for type system. I think generally complex algorithmically complex problems

 

Mm-hmm.

 

are great candidates for that to move the complexity to compile time from runtime as he was saying static analysis right. So I'll reach out to you the day

 

Yeah,

 

after

 

I do.

 

we deploy our first gleam code interaction.

 

That's awesome. That's so cool. Thank you so much. But also reach out beforehand as well. I, I'm super happy to help out with anyone's Glean projects. And it's always really cool to hear what people are doing. And this sort of generally goes, if there are things that people will find useful, uh, when they're making their applications or whatever they're making, you know, that can influence the order of, of, you know, what comes next. Good example would be like the JavaScript backend when, when Peter needed a JavaScript, back the JavaScript backend to the Glinger Piler for, um, you know, something to do with startup at the time, it was something that was planned, but we just moved it forward because that was useful at the time. So yeah, let, let people know what you're doing. I'll be, I'll be very curious if nothing else.

 

Nice. Okay, then I'm unless somebody's gonna scream now, then I'm gonna transition us to pigs. Nobody's screaming. Yeah, so let who wants to start this week? Any, mini, mini, mo. Adi, why don't you start with pigs?

 

I trust you are fair with that little

 

Hehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehehe

 

80-mini money.

 

Hehehehehehe

 

Let's start with a related pick. SpawnFest 2022 is up on the website. You can use any Beam languages, including Gleam there. I'm planning on using at least partially Gleam this year. I wanted to use it last year, but I couldn't because my teammates were... co-senior engineers. This time I picked a couple junior engineers. I can basically do what I want to do. I'm excited for that. It's basically people who don't know it's a 48 hour long free hackathon. You can use Beam related languages and like resolve problems or whatever and it's like, you know judged by you know prominent Beam people. It's free of charge and yeah, you get prices, gift cards and all that stuff. Pretty much it's guaranteed. that you'll get some price because the participation to sponsorship ratio is such. So yeah, there's your incentive to participate. Another pick is stream data for property-based testing. I actually finally used it a couple of months ago, and it's been working so well for us. I know there's proper in our language, which is a bit more complex. But if you guys just wanted to basic property-based testing, just data generation. simple test, no storing states and all that stuff. You don't need to use PropeR. If you're already in the Elixir Train, check out Stream Data, Andrea from the Core Team router. It's really easy to use. Literally will take you five minutes to set up your first property test. It's that simple. So highly recommended. I'm gonna do a repick, what Sasha picked a couple weeks ago and, or maybe three weeks ago, and inspired me to pick up this book, which I'm a huge fan of, specification by example. Part... Sasha is

 

Yay!

 

amazing. Great pick. Yeah, it's it's if you want to be a lead engineer have been a lead engineer it's yeah it's really awesome as an engineer my problem has always been and it's an ongoing you know learning to try to communicate better with non-engineers and be more you know goal-oriented company goal-oriented when I communicate with non-engineers and this book on top of you know communication stuff. It's really on top of all the things that Sasha mentioned it's also helping with communications as well so highly recommended. Yeah please go and check it out. And my video game pick for this week is so Amazon Prime and you know we can talk about whether they suck or not and I'm sure people have different opinions about Amazon but one good advantage of having Prime is they're gonna start to give out free video games every month. AAA game everyone, it's gonna start in September. And September's free game is AC Origins, which is one of the best Assassin's Creed games according to me. So if you wanna play AC Origins for free and you already have a Prime account, you can order it for console or PC or whatever you want. So check it out, it's free and have fun.

 

Nice, that makes me so happy, Arie. Okay, Alan, what are your picks for this week?

 

Yeah, I just have one. I already sent it into the chat a while back, but it is, what did I choose again? It's a new Live View book from Prag Prague. And it's basically how, you have building tables with, table views with Phoenix, right? So I've been trying to get more and more back into Live View. It's just $10 book. I think the, you know, what they give you is pretty good. You know, how to do like infinite scroll. how do you sort data, all this kind of stuff with LiveView. So I think if you want to get more and more into LiveView, it's, they have a really interesting quote in there where it's like, I forgot what they gave, but like basically most of your life is building forms and tables. And so they teach you half of that. And I'm working on a project and I'm doing a lot of stuff. I'm doing the APIs at least. And so yeah, it'd be nice to actually move that stuff over to LiveView instead of using that stupid SPA. So this one I'm gonna be happy using. in my work and just surprising people with. So that's my pick.

 

I think it's really interesting that you picked this book because fun fact, the author, I used to work with him. So small world, I guess.

 

Yeah, I mean, he knows what he's doing, right? I mean, Silence. Hopefully it's going to be good.

 

It's too long ago, it's like, I don't know, four years he was still the only career developer at that point. So it's interesting to see people grow, you know, like I definitely can't make a judgment on his today's skill set. It's I think, yeah, four years could be about right. So but

 

Yeah,

 

yeah, still

 

I mean,

 

kind

 

I've.

 

of funny. Like when I saw the author, I was like, wait, I know that guy.

 

Yeah, I got high hopes for this book. I mean, it seems pretty good. But I just like I got three pages in so far and I'm excited so far. So I'm looking forward to it.

 

Okay, Louis, do you want to do some pics?

 

Yeah, yeah, so I've got one that got an Erlang-y techie one, which I'm really excited by. I don't know if you are familiar with Lumen, but it has since been renamed to Firefly. And this is a Beam language, mostly Erlang to... let me try that again. It compiles Erlang to native via LLVM. So this is really cool, I think. If this... mature sufficiently, we could compile our Glean and Elixir and Erlang programs to native binaries that run super fast, boot really quickly, you know, a single file, you can just drag it to another computer and run it, or to, to WebAssembly that you can run almost anywhere. So I think that's super exciting. And the project kind of stopped till a little while back. And I've just found out this week that, Hey, they're, they're, you know, it's alive and kicking, it's still going. So yeah, really excited to see that. And for my less techy one or different kind of tech. I've bought a Steam Deck or rather I bought one a year ago and it's finally arrived and I've just played and it's really good, you should check that out actually. I've just played the Forgotten City, which is sort of a ancient Rome mystery game. Oh, it's so good. There's not really, there's a little bit of combat. It's a bit rubbishy, but the writing is fantastic. The story is fantastic and the world is fantastic. So check that out. That's really cool. I guess that's my picks.

 

Nice, nice. Yeah, Steam Deck is... I'm still debating with myself.

 

They have to change the name they have to change the name for me to buy it steam deck just I don't know no

 

That's not the issues like mosty. I already have such a backlog of things I have a switch and I have a bunch of games on the switch I haven't played it ever bunch of games on my steam library haven't played it and then I Do I really need this you know?

 

I just really love that I bought a Linux computer purely for gaming. Like that's

 

Yeah,

 

weird.

 

that's pretty cool. That's pretty cool. Let's do it, yeah.

 

But don't you have to install Windows on it for certain things to run properly or something? Again, I don't have experience but I've heard.

 

I don't know how they do it. I think they've like forked wine and made it really amazing because these games are not released for Linux, but they run perfectly and I have absolutely

 

Hmph.

 

no idea how. It's just magic. It's a little magic box with video games on it. It's really cool.

 

Okay, then I'm gonna close it off with two picks. I don't have a techie or whatever pick today. I have two nerdy picks And well, not really nerdy one is not really nerdy one is just popcorn entertainment. Um And the first pick is a series i've been watching very and enjoyed very much that it's called the boys And it's on amazon prime video and the premise is Superheroes are real But let's be honest, in our capitalistic world, what would really happen? There's basically this super huge company, which has most of the heroes under contract. And it's a very dark and gritty, kind of, to be honest, dystopian version of today, with superheroes being real. And also abusing their powers on the regularly, because I mean, if you're fucking Superman, like, what is the police gonna do, right? So, yeah, it's a very... very interesting watch and the plot was basically that like a bunch of average Joe people, guys, they all been wronged by superheroes, they make out and want to get revenge on superheroes, which as is just an average Joe. So it's very interesting series, it's very interesting watch, very entertaining. It's definitely not for the faint-hearted, there is gore, but it's definitely something I've been enjoying a lot lately.

 

What is it called again?

 

The Boys,

 

The boys. The boys.

 

The Boys on Amazon Prime. And my other pick is a card game. I've been playing a lot lately with friends, and basically everybody I've played with loved it. It's called Cabo. And it's a very simple game where you get four cards. You don't know what's on that card. You can look at two at the beginning, and then you need to get the lowest sum of points on the cards. They go from 0 to 13. And yeah, it's just. It's a game of luck, tactic and memory. And it's definitely something very easy to pick up, even for people who don't usually play your games. And still there's a lot of depth to it, so I'm very much enjoying it. And easy to take with you also. Like I've been just chucking it in my backpack wherever I go. And it's easily explained and easily played. So check out Cabo. Those are my two picks for this week. Okay, Louis, it was a pleasure having you.

 

Thank you, it's been really fun. I hope to come back for a third time.

 

Maybe we can start a Glean podcast.

 

Ooh,

 

Adi,

 

that's an

 

Adi,

 

idea.

 

that might be something. Adi's

 

Someone

 

already

 

was

 

nodding.

 

talking about making a mailing list as well. So it's all starting.

 

It's happening, it's happening.

 

It's real. It's real. The social media for it is real.

 

Okay, then yeah, thanks for listening to this episode. Thanks for being here, Alan and Adi. It was a pleasure as usual. And tune in when we have another episode of Elixir Mix. Bye-bye!