I've been learning Elixir and can't believe how incredible BEAM is. I was excited about elixir + Rust NIFs and now there's Gleam! I haven't been this excited in a long time!
i just started to learn elixir and stumbled upon the missing types. i still like elixir and will continue learning it, but this talk and the philosophy behind the language seem so nice. it looks like the language for me. def gonna give it a try!
Louis I love how you get that less is often actually better in programming languages! I think Gleam is maybe the most promising language there is currently.
very cool talk! I really wanna get back into that project where i embedded a js interpreter inside beam i want to use that as like a FaaS like lambda or Deno Deploy something to run sandboxed functions because BEAM is so awesome for scaling
Gleam is the closest to perfection out of all the languages I have seen. It combines the best ideas of many languages I like and importantly adds static types to the BEAM. ❤
I've been playing with gleam. I took it for a test drive and I tried to implement a distributed cache system. The reason I picked this project is because it's something that is somewhat trivial in elixir / erlang because you can leverage a lot of the tools that you get from the BEAM and from OTP. I was able to make the cache but I needed to make a lot of wrappers for the OTP libraries that I wanted. For example the ETS wrapper that showed up on the gleam package manager was really deprecated. It was a bit rough, because you're calling into a dynamic language from a static language which means you're either going to be using the dynamic type or the generic types which might as well be dynamic (that being said, the type inferences pretty good). You have to provide a lot of checks to make sure that you're not pulling in the wrong types or polluting you code with nil/error atoms. I do wish the interrop mechanism was a little bit better in this regard. I also wish there was a code generation tool which could take some of those libraries and create wrappers automatically. From what I can tell there's no metaprogramming in the language as of yet, and I don't think there's a plan to add any kind of macro system. It would be nice to at least have some kind of reflection but I suppose they want to keep things simple. Also, wrapping elixir and especially elixir macros is really difficult. With gleam, the struct types are records, whereas structures in elixir are named maps. I found it easier to interop with erlang then with elixir as a result of this, especially if there is any kind of bi-directional communication between the two languages. Some of these issues will likely fall away as the community becomes more mature but it's definitely early days. I'm kind of surprised that OTP is not included in the stdlib, it makes sense I guess because gleam also targets JavaScript but it would be nice if at the very least there was a package to gain access to the greater beam ecosystem (there is one but it's not complete by a long shot). The other gripe I had revolved around the actor abstraction. I understand why it was different than genserver given there's no function overloading or module level pattern matching, but it didn't feel intuitive at all and at least for now it doesn't have a registry system which is definitely sorely needed. I ended up writing my own wrapper around Genserver and I found that easier to work with. I really like some of the ideas of play in gleam but for now I don't see a reason to switch from elixir or erlang. That being said, I don't think this language is really made for somebody like me who already has a number of years working with the beam, it feels more like gleam is a means of getting more people into the ecosystem which is always a good thing. Anyway, great talk and great language. I'm probably going to contribute to the project in the future because I really think it has a lot of potential to build up our ecosystem and there are some things that I would love to see in the language. Right now, my favorite way of working with the beam is by using elixir and rust together. I find that wrapping rust with elixir is extremely nice because it gets rid of a lot of the downsides of native interface functions via the result and option monads and its built in safety. The biggest downside of NIFs is that they can take down the entire node if they hit undefined behavior, but with rust you can bypass any situation that would give rise to undefined behavior and return a result which maps extremely well on to an ok/error atom set. It would be kind of interesting to be able to do something similar with gleam because it has type safety itself.
Thanks for trying Gleam! The reason for not using gen_server is that it cannot be typed, it was never designed to be sound in that way. The actor abstraction is both type safe and a bit simpler. And good news, there is a registry!
@@lpil No I understand why you guys don't use genserver. Not having function overloading also makes it difficult I am sure. You said there's a registry, but its not in the OTP library from what I can tell. I had to make my own wrappers to use the native beam registry behavior. My thoughts on gleam have changed slightly. I understand the actor a bit more and while I still have a few gripes on the abstraction, its more or less workable. The supervisor on the other hand is an entirely different matter. Its very strange to me that the supervisor is not a process by default (when you call start or start_spec it doesn't spin up a process). I had a situation where a supervisor ended up blocking my program because I had to implement the supervision loop manually. That was another pain point; I wish the API generalized the supervisor behavior a bit more since for now its basically a stub library. In fact, I had an easier time writing my own supervisor using the actor library. Finally the other rough edge was in the FFI. I had a few situations where I hit undefined behavior because the typing wasn't consistent between what erlang outputted and what gleam expected. Erlang uses a lot of union types especially in the OTP libraries, so when wrapping ETS directly, I had to make my own erlang bindings to make sure that the undefined atom was returned as something else, like a result or an option tuple/record. Again though, a lot of this stuff are just pain points that will get solved by the community eventually. When I have some free time, I am going to try to contribute a bit to Gleam because I really like the project.
@@draakisback you don’t need to implement a supervision loop, it does start a process by default. Lots more to come with OTP. I’m focusing on different things currently but we will polish it up in future if no one else does it first.
@@lpil gotcha. Then what I encountered with supervisors must have been a bug because it blocked my main function. I spent an hour trying to figure out what the problem was because I expected the supervisor to spawn a different process from the entry point. I haven't done much with gleam since my original foray into the language since I haven't had any time but I'll go and look again. This time, I think it's probably a better idea to just read the source as the docs aren't as thorough as I'd like atm.
I was always intrigued by Erlang … this seems to be the perfect language For people to start with .. I’m hooked .. how would I convert the typescript /java people to Gleam is the million dollar question
I would love to see work into compile time / macros / metaprogramming, as this won't be nearly as useful for front-end compiled to javascript unless you can have templating syntax embedded (like how Rust is able to have jsx-like templating in Yew / Leptos, which is only possible since the entire rust language is available in macros)
In the Gleam Language Tour, the section on unqualified imports mentions that it is good practice to use qualified imports instead of unqualified imports. This begs the question - for what purpose does the compiler allow unqualified imports if we know that using them degrades code readability and is not a good practice?
Qualified imports are a better default approach, but in some circumstances unqualified ones may be more fitting. The programmer can decide what it optimal for the legibility of the code they are writing.
There’s not much to it really beyond setting `target = “javascript”` in your gleam.toml file. The discord is a good place to get further guidance, and perhaps we can work out what we can put in a guide.
Hi, what are the resources to go from 0 to 100 in Gleam. My main focus is building backend systems, never did anything other than dart and go. Best regards.
This is basically F# from all I can see, plus built-in actors and Erlang tools. Too bad Microsoft doesn't value it nearly as much as C# to hire more devs and improve its tooling.
may i ask why it compiles to javascript? it seems like something that wouldn't be very straightforward and wasm is an option. also, does this limit the language? as far as i understand, you would have to build the language around javascript compatibility. i don't know anything though which is why i'm asking.
The language looks awesome! Strongly typed option makes the BEAM much more appealing to people (like me) coming from the Haskell side of things. 36:36 is kinda a red flag tho. Where do you people even find nazis?
why the aggressive political statements on the website? it won't stop me from using the language but it's going to push a lot of potential users away. i could understand in a discord server or something but it's too much on the front page of the website. i'm not against any of that but it just seems unnecessary and provocative.
@@lpil Emo is sort of a sub-culture that is hard to describe. The stereotypical Emo dressed in all black, trying to look like Gerard from My Chemical Romance. I guess a feminine version of punk.
36:34 and I suddenly lost a bunch of interest in the language, unironically telling people to not be "nzis" is not only weird, you're questioning my common sense.
Owl, you know there are nzis in the world, right? If you aren't one, good for you, you are meeting the bare minimum bar. But some people are, and surely any reasonable person should take a stand against them. Such a strange thing to get triggered about
Louis is such a great speaker.
Man, Gleam is such a cool language. Congrats on the v1 release
I think this is the language im looking for! Great work, will be following closely!
I'm super happy to hear about the improved tooling for editors besides VSCode!
I've been learning Elixir and can't believe how incredible BEAM is. I was excited about elixir + Rust NIFs and now there's Gleam! I haven't been this excited in a long time!
Creating a gleamy language with all the modern tooling is an incredible undertaking. Great job!
Thank you!!
i just started to learn elixir and stumbled upon the missing types. i still like elixir and will continue learning it, but this talk and the philosophy behind the language seem so nice. it looks like the language for me. def gonna give it a try!
I love this language
great talk explaining it
Louis I love how you get that less is often actually better in programming languages! I think Gleam is maybe the most promising language there is currently.
I never thought I would be interested in Gleam or any FP language at all being Java dev myself but here i am
Welcome!
Patiently waiting for stable Gleam release...
1.0 happened like 5 days ago!
Gleam is a well designed language with great branding. I hope it does well!
just needs to remove the butthole/starfish logo and it is A+++
@@nyahhbinghiThey did! Now it's more Mario styled :) ⭐
very cool talk! I really wanna get back into that project where i embedded a js interpreter inside beam i want to use that as like a FaaS like lambda or Deno Deploy something to run sandboxed functions because BEAM is so awesome for scaling
congrats Louis!
This was brilliant!
Gleam is the closest to perfection out of all the languages I have seen. It combines the best ideas of many languages I like and importantly adds static types to the BEAM. ❤
Thank you!
I've been playing with gleam. I took it for a test drive and I tried to implement a distributed cache system. The reason I picked this project is because it's something that is somewhat trivial in elixir / erlang because you can leverage a lot of the tools that you get from the BEAM and from OTP. I was able to make the cache but I needed to make a lot of wrappers for the OTP libraries that I wanted. For example the ETS wrapper that showed up on the gleam package manager was really deprecated. It was a bit rough, because you're calling into a dynamic language from a static language which means you're either going to be using the dynamic type or the generic types which might as well be dynamic (that being said, the type inferences pretty good). You have to provide a lot of checks to make sure that you're not pulling in the wrong types or polluting you code with nil/error atoms.
I do wish the interrop mechanism was a little bit better in this regard. I also wish there was a code generation tool which could take some of those libraries and create wrappers automatically. From what I can tell there's no metaprogramming in the language as of yet, and I don't think there's a plan to add any kind of macro system. It would be nice to at least have some kind of reflection but I suppose they want to keep things simple. Also, wrapping elixir and especially elixir macros is really difficult. With gleam, the struct types are records, whereas structures in elixir are named maps. I found it easier to interop with erlang then with elixir as a result of this, especially if there is any kind of bi-directional communication between the two languages.
Some of these issues will likely fall away as the community becomes more mature but it's definitely early days. I'm kind of surprised that OTP is not included in the stdlib, it makes sense I guess because gleam also targets JavaScript but it would be nice if at the very least there was a package to gain access to the greater beam ecosystem (there is one but it's not complete by a long shot).
The other gripe I had revolved around the actor abstraction. I understand why it was different than genserver given there's no function overloading or module level pattern matching, but it didn't feel intuitive at all and at least for now it doesn't have a registry system which is definitely sorely needed. I ended up writing my own wrapper around Genserver and I found that easier to work with.
I really like some of the ideas of play in gleam but for now I don't see a reason to switch from elixir or erlang. That being said, I don't think this language is really made for somebody like me who already has a number of years working with the beam, it feels more like gleam is a means of getting more people into the ecosystem which is always a good thing. Anyway, great talk and great language. I'm probably going to contribute to the project in the future because I really think it has a lot of potential to build up our ecosystem and there are some things that I would love to see in the language.
Right now, my favorite way of working with the beam is by using elixir and rust together. I find that wrapping rust with elixir is extremely nice because it gets rid of a lot of the downsides of native interface functions via the result and option monads and its built in safety. The biggest downside of NIFs is that they can take down the entire node if they hit undefined behavior, but with rust you can bypass any situation that would give rise to undefined behavior and return a result which maps extremely well on to an ok/error atom set. It would be kind of interesting to be able to do something similar with gleam because it has type safety itself.
Thanks for trying Gleam! The reason for not using gen_server is that it cannot be typed, it was never designed to be sound in that way. The actor abstraction is both type safe and a bit simpler.
And good news, there is a registry!
@@lpil No I understand why you guys don't use genserver. Not having function overloading also makes it difficult I am sure.
You said there's a registry, but its not in the OTP library from what I can tell. I had to make my own wrappers to use the native beam registry behavior.
My thoughts on gleam have changed slightly. I understand the actor a bit more and while I still have a few gripes on the abstraction, its more or less workable.
The supervisor on the other hand is an entirely different matter. Its very strange to me that the supervisor is not a process by default (when you call start or start_spec it doesn't spin up a process). I had a situation where a supervisor ended up blocking my program because I had to implement the supervision loop manually. That was another pain point; I wish the API generalized the supervisor behavior a bit more since for now its basically a stub library. In fact, I had an easier time writing my own supervisor using the actor library.
Finally the other rough edge was in the FFI. I had a few situations where I hit undefined behavior because the typing wasn't consistent between what erlang outputted and what gleam expected. Erlang uses a lot of union types especially in the OTP libraries, so when wrapping ETS directly, I had to make my own erlang bindings to make sure that the undefined atom was returned as something else, like a result or an option tuple/record.
Again though, a lot of this stuff are just pain points that will get solved by the community eventually. When I have some free time, I am going to try to contribute a bit to Gleam because I really like the project.
@@draakisback you don’t need to implement a supervision loop, it does start a process by default.
Lots more to come with OTP. I’m focusing on different things currently but we will polish it up in future if no one else does it first.
@@lpil gotcha. Then what I encountered with supervisors must have been a bug because it blocked my main function. I spent an hour trying to figure out what the problem was because I expected the supervisor to spawn a different process from the entry point.
I haven't done much with gleam since my original foray into the language since I haven't had any time but I'll go and look again. This time, I think it's probably a better idea to just read the source as the docs aren't as thorough as I'd like atm.
Amazing!
big ups King!
I was always intrigued by Erlang … this seems to be the perfect language For people to start with .. I’m hooked .. how would I convert the typescript /java people to Gleam is the million dollar question
dang it I didn't see this talk in the schedule otherwise I would've made sure to pop in... hope you come next year as well!
Great talk
Thank you
I would love to see work into compile time / macros / metaprogramming, as this won't be nearly as useful for front-end compiled to javascript unless you can have templating syntax embedded (like how Rust is able to have jsx-like templating in Yew / Leptos, which is only possible since the entire rust language is available in macros)
Big ups English King!!!!
In the Gleam Language Tour, the section on unqualified imports mentions that it is good practice to use qualified imports instead of unqualified imports. This begs the question - for what purpose does the compiler allow unqualified imports if we know that using them degrades code readability and is not a good practice?
Qualified imports are a better default approach, but in some circumstances unqualified ones may be more fitting. The programmer can decide what it optimal for the legibility of the code they are writing.
Very promising language!
Thank you
big it up
Where to look for an introduction on compiling Gleam into JavaScript for writing frontend?
There’s not much to it really beyond setting `target = “javascript”` in your gleam.toml file. The discord is a good place to get further guidance, and perhaps we can work out what we can put in a guide.
can gleam compile to native? that would be seriously taking golang market share
I don't believe it can. It compiles to Erlang or JavaScript I think
Its compiled to Beam, so it is compiled in the same sense that Java or C# are. There is an IR and virtual machine for GC.
incremental compiler that's as good as TypeScript? TELL ME!
I still find the design choice of not having any date/time functionality in a standard library a bit odd.
Just needs someone to design it, that’s all.
@@lpil ok, so there's still hope :)
Everyone seem to use birl, maybe that's a good candidate to move into official gleam?
Louis - great speech! Can We count on a dark-theme at the Gleam Language Tour?
Yes! Someone is working on it currently.
@@lpil is it trag1c? xD
It's done!
@@lpil I’ve started using it about few days ago. Amazing! My eyes are pleased for this feature! Thanks a lot!
Congrats for v1.0 deployment!
Hi, what are the resources to go from 0 to 100 in Gleam. My main focus is building backend systems, never did anything other than dart and go. Best regards.
The tour is the best place to start! tour.gleam.run/
His voice reminds me of Davy Knowles. Is he Manx?
I have family in The Isle of Man, but I'm from London and I spent a good chunk of my childhood living in Berkshire.
This is basically F# from all I can see, plus built-in actors and Erlang tools. Too bad Microsoft doesn't value it nearly as much as C# to hire more devs and improve its tooling.
It's an ML language so it's like F# at the core, but there's quite a lot different from F# overall.
may i ask why it compiles to javascript? it seems like something that wouldn't be very straightforward and wasm is an option. also, does this limit the language? as far as i understand, you would have to build the language around javascript compatibility. i don't know anything though which is why i'm asking.
It does not limit the language at all and compared to wasm it's very straightforward to target.
how mature is the tooling for compiling to typescript type definitions? would love to ditch typescript pleaseee, don't want to use reasonML
Does He read the comments here?
Btw. A beamy gleamy lang😮
Who know? It’s a mystery
The language looks awesome! Strongly typed option makes the BEAM much more appealing to people (like me) coming from the Haskell side of things.
36:36 is kinda a red flag tho. Where do you people even find nazis?
You’d be surprised.
why the aggressive political statements on the website? it won't stop me from using the language but it's going to push a lot of potential users away. i could understand in a discord server or something but it's too much on the front page of the website. i'm not against any of that but it just seems unnecessary and provocative.
@@front-crook that’s the point
if only they didn't have political statements on the main page of their website
You’re boring
I just wish Gleam had function overloading ;__;
It’s not possible to do while getting the type system experience like Gleam offers. It would need to be more like TypeScript’s types.
@@lpil I wish Gleam had less EMO naming conventions. Lustre, Mist, Dove, Bliss, Pink mascot? Come-on, everyone can't EMO that's naming this stuff.
@@daa5249 What's E.M.O.?
@@lpil Emo is sort of a sub-culture that is hard to describe. The stereotypical Emo dressed in all black, trying to look like Gerard from My Chemical Romance. I guess a feminine version of punk.
@@daa5249 Oh yeah! Not really listened to much but I remember it being huge at the time. I don't see what it has to do with Gleam though.
their tour font for it sucks and use light mode
light mode is for kings, dark mode for newbs
36:34 and I suddenly lost a bunch of interest in the language, unironically telling people to not be "nzis" is not only weird, you're questioning my common sense.
I don't care.
@@lpil Kind of redundant, don't you think? Me telling you I don't care and you telling me that you don't care that I don't care
Owl, you know there are nzis in the world, right? If you aren't one, good for you, you are meeting the bare minimum bar. But some people are, and surely any reasonable person should take a stand against them.
Such a strange thing to get triggered about
I don't really understand what bothered you. Can you explain?
@@owlmostdead9492 I don't care