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!
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 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
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
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.
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)
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.
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.
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?
@@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
