Gleam for Impatient Devs 

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

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 !

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

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.

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.

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

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

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

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

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

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!

Thank you. I love Gleam and its syntax, which looks similar to Rust.

More Gleam content is something I dream of in 2024!

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.

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

At 5:05 should the function be multiply_and_divide() in lines 9-13? If not, how did it get shortened to multiply()?

Love your fast-paced content, just subscribed

Well this looks just lovely.

Great video! What did you use to make the video?

*How can you implement a doubly Linked List in Gleam?* I'm just trying it out nad Gleam is just what i needed, statically typed, Rust like compiler assistance and Rust like syntax but without the Rust slow compile time. its a marriage of things we all needed.

yes, more Gleam, please!

HM So if return statement doesn't exist, so I can't do an early return? :(

Having written a bit of Ocaml, this seems like something I can get into!

Hey, awesome vid! Do you have this video maybe as an article? It's really quick for me, so I'd rather read it than watch it, I think.

This looks really nice. I love functional programming. I tried Ocaml, but it has terrible tooling. F# is pretty good, but many things are still borrowed from C#. This takes the lessons from Rust but applies them to a funtional paradigm, and it looks really promising

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

Ola, tenho uma 48SX muito bem conservada, porem eu dei bobeira e uma das pilhas "vazou" e acabou danificando um dos contatos. Gostaria de envia-la para que voce tentasse conserta-la.

Hope the `use value

Since Gleam compiles to JavaScript, I can't wait for bindings to be created that allow you to write applications such as React or Vue in Gleam. So much security, so much yumminess!

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. That being said, one of the really cool things about how the gleam struct and type system works is that all of the types are based off of tuples. For example, a result type in gleam is actually just a tuple in erlang or elixir that starts with either an ok or error atom. The implication of this is pretty cool, because you can essentially reference all of your gleam types just by appending an atom with the type name to the beginning of a tuple. You can also call any of the gleam functions from one of the other beam languages just by using the module system. The atom gleam@result is equivalent to gleam/result. 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.

What kind of stuff have you been building with Gleam? Have you put it in production for anything?

Gleam looks like a very cool language!

Gleams ints only fall back to float64 like JavaScript when gleam is running in JavaScript. In the erlang backend they are proper unsized ints without max and min value like in Python.

It looks amazing! Like a Rust for humans without tons of syntax garbage. I wish the language to prosper!

I hope it either sets up a trampoline or outputs loops for it's recursion when compiling to JS.

Are you guys aware of any template/project of an RestAPI with good clean code principles made in Gleam? I’m curious to see how the separation of responsibilities would work in a functional language like Gleam 😬

Please more gleam videos!

Gleam are such amazing!

From the first glance of syntax, it seems extremely similar to F#

But is it BLAZINGLY fast?

i would love a deeper Gleam video

Could be ignorance on my part but was looking through gleam stdlib & i didnt find a native networking library, not even TCP clients. Wish you covered calling into/referencing native erlang modules. In elixir its as easy as referencing an erlang module as a symbol/atom (identifier prefixed with a semi colon ':'). Im ocd ab dependencies, thats why i like go alot, its stdlib is robust. Even rust has a native networking library 😢 heck zig has built in http clients & listeners aswell 😂

But I'm wondering why/what problem gleam can but others can't solve?

id like to see some stuff you tried to build in gleam! even if its just code challenges. Been reading functional programming in python but maybe i should try in gleam to push myself even further!

I want type annotation to be required. I guess you can grow a list by spreading it into a new list together with the new elements?

I watched the video and usage of linked lists as basic lists blown my mind, can someone explain me why gleam devs took such desicion in language design??? I always heard that for modern cpus linked lists almost always worse than arrays because they are really hard to cache in l1, l2, l3 cpu caches due to them being despersed in memory, so in my view it just looks like a big perfomance hit out of the box.

Yeah, the only unique thing that this brings with it is that it has the option to compile to javascript and that it already has static typing built-in. I would still prefer to use Elixir though since it is more mature, has a larger ecosystem, and is already battle tested. And with the progress on Elixir's static type system coming "relatively soon", I don't see why people would choose to use Gleam over Elixir at that point. If you need javascript, why not just directly use javascript (or Typescript) instead? And if you need BEAM stuff, I would argue that Elixir is still a better choice.

We need something in production to run with Gleam

Gleam looks awesome. Only thing i hate is lack of early returns. Can easily cause nesting hell

Not having if-else statements is certainly an odd one. I'd like to build something with Gleam just to see how far pattern matching can take me.

But what are people actually making in it? I checked the package registry and awesome-gleam repo and everything seems extremely young. I also fear for the double compilation model, right now it seems like people are either making libs targeting js _or_ beam, not supporting both. This is a pretty major red flag for the ecosystem moving forward

Ok I was lovin' it until you said it doesn't have early returns?! Wtf! Doesn't that mean you cannot extract edge-cases and handle them first? You now have to nest your if-else's. I've never touched a functional language so I don't know if there's a common pattern for this, but I find it crazy.

Something wrong at 1:55 on line 4. Assigning the string "Skyrim" to a variable named best_game should result in an unbiasedBadTaste error

6:48 typo Andrew -> Mr Clark

Can you do Grain next?

Can't tell whether this looks like more convenient Haskell or less convenient Haskell, lol

Not having loops is just an alien concept to me.

I love to see functional programming leaking into javascript dev land :P

If only I knew I could have just not added things like return I might have finished my scripting language lmao.

Okay, no ifs is a bit weird but I can live without it, but no early returns and no float mods are pretty much deal breakers for me. I’m not even sure when you would use a mod operator when it’s not a float…?

Now this is what functional languages were supposed to be

No install info on Linux 💀

2:31 Why is that needed?

do Odin next ❤

Can you make Linux commands for impatient devs pls?

Came to elixir and keep your heart on it

Looking at backend benchmarks, every single language on beam vm is very slow, like slower than php slow

2:21 I am not thrilled that x/0===0 that sounds pretty risky to not check for that

Rust with a GC

Gleam is the closest language to perfect that I can find.

Some Gleam's features remind me Ada.

It changed my perspective when I realized that whenever you learn a new language, you are learning the philosophy of another person. So dont waste your time learning books upon books of philosophies of different people and never sticking to at least one and using it for real. I personally dislike the /0 returning 0, the use of {} for math priority and for concatenation of strings.

It's OcamL with brackets

I was excited until i saw recursion and then remembered my beef with erlang

Someone pythonified my rust D:

Gleam sounds cool! Although i feel like defining 'x / 0 = 0' should be a crime

The only thing I’m not a huge fan of, is allowing FFIs. Would prefer if they went the Elm route and created their own package manager and all projects be strictly Gleam.

spaceship operator

I am missing UFCS, but cool language

Oh no. Division by 0 is zero. What could possibly go wrong?

seems to be mix between typescript and python :)

Lists are homogeneous. Tuples are heterogenous.

Sounds like the well-protected child of Rust and Typescript. From Rust it has learnt that the world is hard and evil and that you have to reckon with everything. From Typescript it has learnt to strike a softer note. I prefer to stick with Rust because I always want to know explicitly what's going on, the world is still hard and evil and I have to reckon with everything.

I don't know any coding yet I'm watching this. I have a problem. And his name is the Primeagen.

The function returns the last expression???? Cuteness and that always ends the same way

"Lists are heterogeneous" ... wait. what? EDIT: oh it was just a mistake that you acknowledged below. phew

This looks a lot like rescript

How is something divided by 0 equal to 0 💀💀

please, compile to native instead of just beam

It's disgusting how everyone claims it's designed to create scalable applications and it's fast and whatnot even though it's never been used in production...

No instructions for Linux, despite it being popular among developers.

I don't get it. Why have different operators for floats?

Can zoomers use this language?

Ugh... It enforces snake case...

It was all fun and games, but you lost me on "gleam does not uses parenthesis to determine order of operation"

"Has Nil" "No null or undefined" I don't think that's quite accurate

Any number divided by zero is zero? Ew. Standards are defined for a reason, and IEEE-754 defined Division By Zero as equaling +Inf. There's other parts of the language I don't like, but I also like C#, so take my words with a grain of salt lol

division by zero = zero is bs

Anyone else not really like the this language from just seeing this one video? Seems unnecessarily clunky. The pattern matching is neat though

Idk, just use Elixir? Much more mature and better