Gleam for Impatient Devs

In a world where we increasingly worry about memory safety and low-level performance, one language is paying more attention to building stable, reliable concurrent systems. That language is Gleam, a new way to write functional code for the Erlang BEAM VM.

Check out my articles on Polar:

Resources:

__________________________________________

Check out my other socials!
__________________________________________

Timestamps:
00:00 - Introduction to Gleam
00:35 - Installing Gleam
00:48 - Gleam project structure
01:07 - Variables and data types
02:20 - Operators
02:41 - Blocks
02:56 - Imports
03:20 - Lists
03:43 - Pattern matching
04:40 - Functions
05:52 - Recursion
06:15 - Compound data types
07:19 - Modules
07:38 - Use
08:01 - Your Gleam journey

#gleam #softwareengineer

[chxmpetre]

Great explanation! We're currently in the process of overhauling the gleam language tour into something moke akin to a proper "book of Gleam", your take on explaing all theses language features lends itself so well for that !

[bpo]

I also would like more Gleam videos. Similar to what some are saying it's like a blend of Rust (without borrow checker), Haskell (without baggage), and Go (simplicity). The fact that 1.0 made sure to have incredible tooling and access to a huge ecosystem along with the simplicity of the language makes it the real deal. You can get things done really quickly right now. The creator is cool, too. As a long time dev I feel the need to put this out there because the language really is quite good. Give it a whirl on a real project you'll be really happy.

[ImHencke]

Gleam looks like Rust and Haskell had a child with a sprinkle of typescript

[michallepicki]

small mistake at 3:23, Gleam list are homogeneous, not heterogeneous

[iamcookbook]

I love the speed of these videos! I feel like you just dumped a ton of information into my brain and saved me so much time.

[harrynair]

Gleam puts Erlang back into interesting choices to have in production. Of all the languages Erlang is one among the few where concurrency is baked in as a first class citizen and not an after thought, but the syntax is really weird and doesn’t have type safety either. Gleam gets that fun element back in and for all those who worry should I put this production- Erlang runtime has been out in production for decades and is mature. It is akin to ask shall I put apps written in Java, scala, or kotlin in production- it doesn’t really matter as it is the runtime (jre) that executes those instructions

[gadgetboyplaysmc]

Holy shit it's like every fact I see here it's so comprehensible that I didn't need to pause for a long time. That's kind of a testament to how simplicity is crafted into the language. Very cool

[draakisback]

I like gleam but it's definitely got its rough edges, I say this is somebody who writes elixir and erlang pretty often. I suppose that puts me in the minority given that a lot of people are probably approaching this language from languages outside of the beam.

Where gleam has its rough edges comes from its interoperability specifically with elixir but also with erlang. Obviously, when you are importing the functions and types from dynamic languages, it becomes more difficult to make sure that everything is type safe. I do hope they make the FFI a little bit more sane as right now most of my wrapper functions either have to use the dynamic type or a generic. You can, by the way, hit situations where you have undefined types if your FFI type doesn't cover all of the incoming types. Because gleam has no way of handling undefined, there's nothing you can really do about it except to try to expand the wrappers.


The other pretty big rough edge is the actor and supervisor implementation. The supervisor implementation specifically is really limited because it doesn't really implement a lot of functionality. In elixir, when you set up a supervisor, it's a actor that watches your other actors and handles fall over situations and errors. In gleam though, the supervisor isn't a process by default, which means it can block your entry point process. And because the way the actors work, you can't just spin up a task or another process to delegate the underlying supervision loop. What ends up happening is that you kind of have to add many layers of abstraction to make it work properly. I had to implement an entire registry just to get the actor subjects for the child actors of the supervisor so that it could link to them properly.

And that's where the actor abstraction is also kind of rough. For an actor to talk to another actor, it needs to know about that actors subject, which is basically it's process ID. This means that there are a lot of instances where both actors need to have a way of getting the other's subject.

If one of these actors falls over, you need to regenerate the subject to be able to restore communication, and so every single actor ends up having some kind of message to make this easier. In elixir or erlang, you can take advantage of linking and the registry to find another actor but you can't do this in gleam, at least not yet.

All of these rough spots are things that will probably get fixed with time, but they definitely stop me from using this language over elixir or erlang right now. Since they are adding a type system to elixir, it's going to be much difficult for me to want to switch. That being said, I can't complain about the beam getting more attention given that it's such a fantastic piece of software.

Right now, one of my favorite ways of using the beam is to mix rust and elixir together. If you wrap rust with elixir, you get this really nice pairing because of the way that rust handles errors. In the beam, if you want to reference native code, you can use native interface functions. The major downside of nifs is that they can cause the entire node to fall over if they end up hitting undefined behavior. This makes it so that your app is not nearly as fault tolerant as it should be. But with rust, you can use the result type or the option type to handle the situations where you would have had to deal with undefined or null behavior. In other words, if you write very pure functions in rust, then you have a guarantee that the nif will never take down your node.

Sorry for the wall of text, just extremely passionate about this. Even though I've used elixir in my job for almost 8 years now, I still find it to be really fun to use.

[brielov]

I would love more gleam videos. Specially networking stuff like sockets and such. Thanks for sharing this!

[MichaelCampbell]

Been watching Gleam from the sidelines for a long time. I really like the typed aspect. Waiting for a killer Phoenix-like framework for it.

[deryilz]

cool! another great video. gleam looks like a very clean rust...

[trwn]

Best way to try out Gleam: Implement a library for a custom Fraction type. :D

It worked like a charm!!! 🎉

[ausd]

Gleam seems really neat. I'm excited about it. Thanks for covering it!

[kellybmackenzie]

I adore how Haskell-like this is! I'm absolutely gonna give this language a try!
5:20 I love this, it's basically partial function application, that's awesome!

[DisFunctor]

Alright alright, I'm digging this. Scala is one of my favorite languages and I'm quite happy with it, but I've been looking into broadening my horizons and Gleam seems to share a lot in common (strong pattern matching, strongly and statically typed, garbage collected, heck even getting strong for-comprehension vibes from 7:45)
I gotta say I'm sold on this. I was leaning towards Elixir before, but now I might bump this one up on my priorities list.

[tacticalassaultanteater]

Great video, covered all of the main points of interest.

[weiSane]

For a second there I thought you were writing rust. Then I remembered it’s a gleam quick tutorial.

[coder_one]

More Gleam content is something I dream of in 2024!

[TheMASTERshadows]

Thank you so much !!! The pacing is soooo gooood

[葛帝恩]

I fail to see how this is more advanced than 50-year old Standard ML