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 !
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.
@@IsaacHarrisHolt I'd recommend doing a simple toy project that you want to build and see if it can do it! My personal journey is a custom file that stores records (serialize, deserialize, string parsing, io) but I wanted it to run on the Beam AND in Javascript. That gave me a bunch of insight into code organization, naming, and how to write something that targets one or the other or both (lots of standard library exploration plus some other common packages on hex.pm). A concurrent server like tcp or udp seems like a great choice too!
@@IsaacHarrisHolt Do a simple toy project you want to build which has multiple source code files and touches the file system. I did something with these criteria and I learned how to organize a gleam project, how gleam names things, importing a gleam package using the tooling, setting up formatting for Gleam in Nvim, and how pleasant the language is. A simple TCP server would be a good example. After working with it even more it feels a lot like OCaml with even less options on how to do things. It leads to very readable and a pleasant functional (the paradigm) code base. It's honestly functional Go. Go is more mature obviously but v1 Gleam is the functional language I have been waiting for.
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
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.
@@IsaacHarrisHolt Thanks mate. I am probably going to contribute to Gleam since I like the project but its always a good thing to get feedback regardless.
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
I like this take a lot, but you can still have bugs in a programming language even if the runtime is mature. There could still be bad allocations, etc that cause memory leaks. That said, Gleam is being used in prod by Fly.io, so I trust it
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!
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.
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!
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
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.
"Relatively soon" has been promised for a while. Gleam is also being used in production at Fly.io, so it's definitely prod-ready. The nice part about the transpilation is that you can write one language for frontend and backend without having to use JS directly or a WASM-compiled language. Gleam also just feels more familiar to devs coming from C-like languages, so I think it's well-placed to drive adoption of FP
@@IsaacHarrisHolt Yeah that's why I put "relatively soon" in quotes. There is still no ETA of when it will be ready for use. Maybe i'm just a bit skeptical about the "one language for both frontend & backend" thing since a lot of people would argue that Javascript on the backend was a mistake. Of course, reality is a bit more nuanced than that. In a lot of cases (if not most), using javascript on the backend is fine for as long as performance isn't critical. If this does indeed help to drive adoption for FP then I would see it as a net win. I would still recommend you at least take a look at Elixir though (since you mentioned in the video that Gleam was the first FP language that you have tried). Elixir, together with Phoenix & Phoenix Liveview make it possible to create full stack applications without touching any Javascript (or at least keeping it to the bare minimum).
I do want to look at Elixir for sure, but I'm gonna stick with Gleam for a while to make sure I understand BEAM etc. before moving on. I already spend too much time chasing shiny new things!
@@IsaacHarrisHolt Totally get the feeling. I myself am still not adept at using Elixir and I was first introduced to it (& Phoenix) back in 2020. I haven't used it in production and I constantly restart my own projects with it so I haven't actually built anything using Elixir yet lol.
no expert, but I don't think you can, you just have to write more functions...frankly function overloading and early return are useful - the user should have a choice
You have to write more functions, sure, but then you can call them using a case statement. The lack of early returns forces you to keep functions small in some cases, which makes the code a lot more readable
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.
@@IsaacHarrisHolt Yea, you are right. You said "On the Erlang vm these have no minimum or maximum size, but they are represented by the number type in JavaScript" at 1:30, but I misunderstood it as "They have no minimum/maximum size, but they function the same as float64 does in JavaScript everywhere", which shocked me, as that would be a horrible decision. (So I thought the "but" references the type in Erlang and not switching the sentence to the javascript backend).
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…?
You could use it to create a round robin counter (e.g. 0, 1, 2, 0, 1, 2, ...) without needing if statements etc (e.g. counter = { counter + 1 } % 3). A lack of early returns is pretty common for a functional language, and you can achieve most of what you need by separating into multiple functions and using case statements.
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
It is pretty young because the language is. I don't think the double compilation thing is necessarily a red flag. Some libraries will support both, while some will be specific. It's no different from a JS library being frontend or backend only.
@@IsaacHarrisHolt That's fair, I just don't really understand why people are hyping up the language when it's not particularly good at anything just yet. I like the syntax and the vision for the project, but that's about all there is to say right now. And yeah not saying it's a problem specific to gleam, I'd argue node.js also got this very wrong by not attempting to be as browser-compatible as possible. I just think languages could be doing a lot better at being cross-platform, just having an ffi and letting userspace do the rest of the work isn't particularly interesting as even ancient languages like C already do the exact same thing
That's the problem with C though, at this point. There's an article I read somewhere about C being more of an API language than a programming language now. It's mostly used by other programming languages interfacing with the OS
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.
I'd say its a bit of a trade off. On one hand it can sometimes feel uncomfortable to need to organize your code around this design choice in the language but on the other you can always and forever know for sure that the last statement in any function is what it returns. Pattern matching does typically take most of the edge off that discomfort though. The biggest hurdle is getting comfortable with it all; when I first learned erlang my brain felt broken 2-3 weeks until it clicked, then it felt surprisingly natural and ergonomic.
You only really want to do an early return in two cases i can think of. One is to break out of a loop early, which gleam doesnt have any loops so no need there. Or another is some special condition is met, where you want to return something before going on to do other things. That is covered by pattern matching as others have said. In functional programming in general, you want to try to make your functions as small / simple as possible, and compose them from other functions. So you typically wont run into a problem where you wish you could use an early return, because the function is so small anyways.
And regarding deep nesting issues, you can usually use monads to "short circuit" a complicated tree of code paths into a single linear path. Sorry to use the word monad there as if you are new to FP it is just going to send you down an annoying, but hopefully interesting, rabbit hole. But the main idea is to think of it as short circuiting in this case. Like, do thing A that might return a result or an error (edge case), and then push that result if it exists into a function to do things with that valid result, otherwise just return the error / bubble it up. Usually the errors that are bubbled up are dealt with at the top of the call stack
You can still get nesting hell with early returns 😅 you just have a different way of dealing with it. With functional languages, you use case statements and more functions
I really like type Inference but parameter and return type of a function should not be optional a function signature should tell you what the function does without the need to read the body.
i know other functional languages have it, but pattern matching against multiple variables at once always makes me think of COBOL :) i'll take a look at the concurrency model of erlang/beam/gleam. i hope it's ok. i'm starting to worry that go has spoiled me for every other language here .
You'll find it very similar! Like in Go, you don't have to deal with function colouring, you can spawn short lived or long lived tasks, etc.. Take a look at my concurrency video and let me know what you think
@@IsaacHarrisHolt ok, thanks for the video. for me i really like your pacing and the way you build things up to include real-world scenarios. in my opinion the number of functions for dealing with concurrency in gleam/beam is just huge. i also haven't seen a way to organize shutting down of actors. this is one of the things go makes trivial with close(chan) which will cause all listeners to exit their foreach(chan) loops. the way i see it, go offers more functionality with fewer primitives. i imagine i *could* learn to do concurrency with gleam/beam, but i'd be unsure how to build up a dag and then cleanly power it down, for example.
This is a fair point - it's a lot to learn, but in exchange you get a very powerful concurrency model that doesn't have all the same footguns as Go channels (which, sadly, do ruin the experience sometimes). In terms of closing an actor, you'd just have a Shutdown variant of your message that the actor handles by returning an actor.stop() (I think that's what it's called). It's ultimately very similar to closing a channel except you don't have the extra function.
@@IsaacHarrisHolt yep, one needs to know best practices for concurrency in go. Though it's related to best practices in any language with mutable state, I think. The advantage of close for go channels is that it disconnects all listeners, not just one.
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 😬
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!
Take a look at my isaacharrisholt/youtube repo! There's a PR there for an upcoming Gleam video. It's my first time writing Gleam/FP though, so it's not perfect yet
Never got to looking into Gleam. It seems to me like dumbed Erlang. Looks more JS-like for sure, but I'm not sure what the benefits are and if they are worth the cuts. Elixir adds to Erlang, this... seems to kinda make it JS compatible. I.e. looks like lowest common denominator situation to me. Yeah explicit types and stuff and corporate setting development, but that' like Scrum of a programming language.
Gleam adds static typing, mostly. It's 100% Erlang-compatible otherwise, and you get all the great features of the BEAM VM. But yes, there's some stuff Elixir adds that Gleam can't.
For loops are practically pointless in a language like Gleam where data is immutable. It's very common for functional programming languages (like Gleam, Erlang, Elixir, Haskell) not to have loops for this reason. As for if/else statements, one of Gleam's biggest values is simplicity. Since if/else can be accomplished with a case statement (and should actually be more performant than long if/else if chains on the BEAM target), there's no reason to have if/else. The goal is to minimise the surface area of the language, effectively. For example: ``` if cond { func1() } else { func2() } ``` becomes ``` case cond { True -> func1() False -> func2() } ``` You can also match on multiple values in a case statement, and that tends to be easier to read than a long if/else with lots of boolean logic.
Of course! The predicate can be any value you can match on: ``` case is_something_good() { True -> do_another_thing() False -> cry() } ``` You can even match on strings etc. ``` case name { "Isaac" -> do_something() "Ernst" -> do_something_else() _ -> panic as "Unknown name!" } ```
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.
I understand the reasoning, but since they're running primarily on the BEAM anyway, allowing FFIs gives access to the incredible Erlang ecosystem. It's also the primary reason they're able to use OTP APIs for concurrency (more in my next video!) and fault tolerant, scalable systems.
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 😂
The reason there's no networking in the stdlib is because of Gleam's multiple targets. The networking layer looks different depending on whether you're on Erlang or JavaScript. There are first party networking libs available though that already do the referencing for you: gleam_httpc for Erlang and gleam_fetch for JS. As for using FFI yourself, it's covered in the Gleam tour! tour.gleam.run
@@IsaacHarrisHolt I would really like to hear about what its MOST optimized for and what niche (if any) you think it will be adopted by. What type of projects do you think will Gleam be chosen for? Do you think it will be a general purpose language? Or be utilized exclusively by a whole industry like Elixir and Erlang have with Telecom? What does it do well and not so well? This is the first opportunity Ive had to try a brand new language and im kinda excited to try it
Interesting! I think Gleam's path is yet to be set, to be honest. Telecoms is probably going to adopt it at some point given it runs on the BEAM, but it's also got potential uses in web development and other areas. Honestly I can't predict the future, and it's still a very young language. I think the community will shape the language a lot in the coming years.
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.
That's totally fair. There are very good reasons for all of these, but there are equally good reasons for not doing them, so I definitely see your point. The last one, concatenation, is so that Gleam can infer when something needs to be a string over an int, float etc. and can therefore keep things statically-typed without needing to have type annotations everywhere
No loops except by recursion? How deep is the call stack? Seems like it will be hard to do an infinite loop unless you also have infinite ram to store all the return addresses
There's tail call optimisation, which keeps the call stack nice and light. Also, the BEAM is made to handle this sort of thing, so it can go pretty deep pretty efficiently
You can match mutiple values at once separated by comma. And wildcard any one or more. And assign the matches to a local const var easily. And qualify the match with an if guard. It's incredible.
It is pretty good, but I do wish you could do more complex string matching. For example, I'd love to be able to extract values without having to do regex: ``` case log_line { "[" level "]: " message -> ... _ -> ... } ``` Same with lists - you can only match on the beginning of the list (though I understand the performance implications for both of these).
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.
Gleam (and other BEAM VM languages) aren't performance focused. Using a single linked list makes sense when the list is immutable, and allows you to reduce memory usage by sharing the tail of the list across multiple variables etc. If an array was used instead, there would have to be a lot of memory copying to get the same immutability
@@IsaacHarrisHolt and specifically in functional this would be the worst feature ever. Imagine multiple returns? I mean my God what a bad thing to watch
Nil is its own type, and can't be assigned to anything else. It's like () in Rust. The if keyword is only for guards in pattern matching, and it's fairly common to not have branching in functional programming languages
No loops, can't return early, no if/else, non-standard math syntax... definitely will be a hard sell. It's difficult enough to get adoption of rust, nevermind that lol
@@harrynair1811 yeah i'm not worried about Erlang but sometimes issues with a language's ergonomics or other challenges don't really become apparent until you start building real stuff with it
@SeanLazer apologies, I've just learned I may be wrong here. Apparently Fly are just the sponsor and might not use it in production. You can definitely deploy Gleam to Fly though, so there's nothing stopping you trying it for free/cheap!
@@IsaacHarrisHolt i get how it might be good im some cases, its just that it fucks with pure math. I feel like this breaks at least 5 Axioms in the Field of Real Numbers under multiplication and addition.
Gleam doesn't have the concept of infinity, and this result is actually quite common for BEAM languages. It's about making sure things don't crash as much as possible
@@IsaacHarrisHolt how do you let the user know which types a function expects without type annotation, and how does the function guarantee that it receives correct types without type annotation?
It means you can give things nice names that make sense externally when calling the function and then a different one for use within the function body. There are some good examples in the standard library
*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.
I don't know how you'd go about implementing a doubly linked list - there's probably a way, but it might involve writing Erlang instead. But I'm glad you like Gleam :)
Iterative loops are usually implemented in functional languages as map/fold/reduce/accumulate and the likes. The body inside the "for" is given as a function which returns the result and and the state for the next iteration. Example in pseudo code. Instead of: sum = 0 for item in list: sum += item You have: sum = fold(list, 0, fn(cur, state) { cur + state })
I mean if you think about it a for and while loop is just a recursive call after a comparison. “If this condition isn’t met do this again”.. The only difference is recursion is wrapped inside its own function. And functional languages use function overloading so you have a base case function and a recursive case function.
BEAM was originally purpose built for high reliability and concurrency in critical telecom infrastructure, it deliberately trades raw speed to achieve this but it is generally considered *at least* fast enough for most use cases where its qualities are desirable. The success of tools like RabbitMQ and EjabberD at massive scale demonstrate this.
@@formyeve Don't do recursion directly. For most things, a map/fold/reduce/accumulate etc is more than enough. You only need custom recursion in rare cases.
Gleam looks like Rust and Haskell had a child with a sprinkle of typescript
It's a really good language. The simplicity feels like you're writing Go. There's absolutely 0 magic it's great
That's the most accurate description I can think of. My brain will not leave me alone with the idea of transpiling Gleam into Rust.
See also F#, seems quite similar to Gleam.
Ocaml forever forgotten
@@meppieomg Whatever floats your functional boat
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 !
I'd love to help! Give me a shout on Discord at any time :)
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'm definitely going to! Anything you recommend?
@@IsaacHarrisHolt I'd recommend doing a simple toy project that you want to build and see if it can do it! My personal journey is a custom file that stores records (serialize, deserialize, string parsing, io) but I wanted it to run on the Beam AND in Javascript. That gave me a bunch of insight into code organization, naming, and how to write something that targets one or the other or both (lots of standard library exploration plus some other common packages on hex.pm). A concurrent server like tcp or udp seems like a great choice too!
@@IsaacHarrisHolt Do a simple toy project you want to build which has multiple source code files and touches the file system. I did something with these criteria and I learned how to organize a gleam project, how gleam names things, importing a gleam package using the tooling, setting up formatting for Gleam in Nvim, and how pleasant the language is. A simple TCP server would be a good example. After working with it even more it feels a lot like OCaml with even less options on how to do things. It leads to very readable and a pleasant functional (the paradigm) code base. It's honestly functional Go. Go is more mature obviously but v1 Gleam is the functional language I have been waiting for.
That's very helpful, tysm!
@@bpo217 This is excellent advice for learning any language.
small mistake at 3:23, Gleam list are homogeneous, not heterogeneous
You're right, thank you! I always get those confused
homosexuals like the same, heterosexual like different, that's how I memorised this :D
Best way to try out Gleam: Implement a library for a custom Fraction type. :D
It worked like a charm!!! 🎉
Awesome!
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
Yeah, simplicity is very much at the core of every decision the team makes
I would love more gleam videos. Specially networking stuff like sockets and such. Thanks for sharing this!
I will get on that! I also want to dive more into concurrency - I've never used a BEAM language before, so it's fascinating to me
@@IsaacHarrisHolterlang is awesome, i use it at work. i would highly recommend checking out the OTP principles
It's definitely something I'm gonna be looking into soon!
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.
No, this is great! I hope you don't mind, but I've actually forwarded your thoughts to the Gleam team to take a look at
@@IsaacHarrisHolt Thanks mate. I am probably going to contribute to Gleam since I like the project but its always a good thing to get feedback regardless.
Likewise! I'm trying to figure out how it all works at the moment
This was a super insightful commentary, thanks for sharing it with us
Of course!
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.
I'm glad you found it helpful!
I'm the opposite. I find it a bit too fast for my liking. However I can see the value in it if you can comprehend things faster.
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
I like this take a lot, but you can still have bugs in a programming language even if the runtime is mature. There could still be bad allocations, etc that cause memory leaks.
That said, Gleam is being used in prod by Fly.io, so I trust it
Gleam seems really neat. I'm excited about it. Thanks for covering it!
Let me know what you build!
Great video, covered all of the main points of interest.
Thanks! Glad you found it useful
More Gleam content is something I dream of in 2024!
On it!
Doing it too now!
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.
Take a look at Lustre! I'm not sure it's going all the way to Phoenix, but it's progressing
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!
Go for it! Let me know what you create
Thank you so much !!! The pacing is soooo gooood
Thanks! I hope you found it helpful!
@@IsaacHarrisHolt Yes, next weekend project will be in Gleam for sure !
Good luck! I'm interested to see what you come up with :)
cool! another great video. gleam looks like a very clean rust...
Thank you! Yes, I really like Gleam. It feels like Go + Rust minus methods. It's a fun language to write
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.
Gleam is an awesome language, and the community is very welcoming. Definitely recommend checking it out!
Thank you. I love Gleam and its syntax, which looks similar to Rust.
It's great!
It looks amazing! Like a Rust for humans without tons of syntax garbage. I wish the language to prosper!
It's great!
For a second there I thought you were writing rust. Then I remembered it’s a gleam quick tutorial.
It's so interesting that a lot of people have this opinion. Personally I think it's more like Go, but I do see where you're coming from.
yes, more Gleam, please!
Working on it!
Skyrim mentioned🔥🔥🔥
I used to be an adventurer like you...
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!
Nothing stopping you from creating them ;)
@@IsaacHarrisHolt my knowledge about Gleam and functional programming is not enough (I hope this will change).
No better way to learn than a project!
Interesting language. Lot to love
Agreed! I do love it
But is it BLAZINGLY fast?
Not particularly - BEAM languages are better for fault tolerance and concurrency than raw speed
Gleam looks like a very cool language!
It is! I recommend checking it out
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
Interesting! I thought OCaml tooling had improved. I do remember having some difficulty getting set up initially though
Having written a bit of Ocaml, this seems like something I can get into!
Awesome! I want to try OCaml myself, but I think I'm gonna go all in on Gleam for a while
@@IsaacHarrisHolt OCaml is good but the concurrency model is unclear...Erlang/BEAM is proven
Yeah, the BEAM is really cool. I've been paying around with it a fair bit
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.
Their ecosystems are the same. You can use every erlang and elixir package with gleam already.
"Relatively soon" has been promised for a while. Gleam is also being used in production at Fly.io, so it's definitely prod-ready. The nice part about the transpilation is that you can write one language for frontend and backend without having to use JS directly or a WASM-compiled language.
Gleam also just feels more familiar to devs coming from C-like languages, so I think it's well-placed to drive adoption of FP
@@IsaacHarrisHolt Yeah that's why I put "relatively soon" in quotes. There is still no ETA of when it will be ready for use.
Maybe i'm just a bit skeptical about the "one language for both frontend & backend" thing since a lot of people would argue that Javascript on the backend was a mistake. Of course, reality is a bit more nuanced than that. In a lot of cases (if not most), using javascript on the backend is fine for as long as performance isn't critical.
If this does indeed help to drive adoption for FP then I would see it as a net win. I would still recommend you at least take a look at Elixir though (since you mentioned in the video that Gleam was the first FP language that you have tried). Elixir, together with Phoenix & Phoenix Liveview make it possible to create full stack applications without touching any Javascript (or at least keeping it to the bare minimum).
I do want to look at Elixir for sure, but I'm gonna stick with Gleam for a while to make sure I understand BEAM etc. before moving on. I already spend too much time chasing shiny new things!
@@IsaacHarrisHolt Totally get the feeling. I myself am still not adept at using Elixir and I was first introduced to it (& Phoenix) back in 2020. I haven't used it in production and I constantly restart my own projects with it so I haven't actually built anything using Elixir yet lol.
HM
So if return statement doesn't exist, so I can't do an early return? :(
Correct! You can use a case statement instead
no expert, but I don't think you can, you just have to write more functions...frankly function overloading and early return are useful - the user should have a choice
You have to write more functions, sure, but then you can call them using a case statement. The lack of early returns forces you to keep functions small in some cases, which makes the code a lot more readable
Hope the `use value
Elixir has "with x
Interesting!
Roc has a similar thing called backpassing
@@kilianvounckx9904 good to know! Roc looks really interesting
None can beat elagance and simplicity of standard ML. Wish sml compiled to JS
I had a quick look, and it does look really nice! Not sure about the iterative parts, but otherwise it's great
Awesome video, appreciate the speed. At 3.20 ish you say lists are heterogeneous, did you mean homogeneous?
I did! I believe I've corrected this in the pinned comment :)
Oops, missed that, thanks!
Not a problem!
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.
Correct! I believe that's what I said in the video. Happy to correct myself if I was wrong 😅
@@IsaacHarrisHolt Yea, you are right. You said "On the Erlang vm these have no minimum or maximum size, but they are represented by the number type in JavaScript" at 1:30, but I misunderstood it as "They have no minimum/maximum size, but they function the same as float64 does in JavaScript everywhere", which shocked me, as that would be a horrible decision. (So I thought the "but" references the type in Erlang and not switching the sentence to the javascript backend).
Ah, sorry for the confusion!
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…?
You could use it to create a round robin counter (e.g. 0, 1, 2, 0, 1, 2, ...) without needing if statements etc (e.g. counter = { counter + 1 } % 3).
A lack of early returns is pretty common for a functional language, and you can achieve most of what you need by separating into multiple functions and using case statements.
Love your fast-paced content, just subscribed
Thank you!
Well this looks just lovely.
It is! The people are great too
Please more gleam videos!
On it!
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
It is pretty young because the language is. I don't think the double compilation thing is necessarily a red flag. Some libraries will support both, while some will be specific.
It's no different from a JS library being frontend or backend only.
@@IsaacHarrisHolt That's fair, I just don't really understand why people are hyping up the language when it's not particularly good at anything just yet.
I like the syntax and the vision for the project, but that's about all there is to say right now.
And yeah not saying it's a problem specific to gleam, I'd argue node.js also got this very wrong by not attempting to be as browser-compatible as possible.
I just think languages could be doing a lot better at being cross-platform, just having an ffi and letting userspace do the rest of the work isn't particularly interesting as even ancient languages like C already do the exact same thing
That's the problem with C though, at this point. There's an article I read somewhere about C being more of an API language than a programming language now. It's mostly used by other programming languages interfacing with the OS
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.
It's a pretty common pattern. You'd normally handle it with pattern matching :)
I'd say its a bit of a trade off. On one hand it can sometimes feel uncomfortable to need to organize your code around this design choice in the language but on the other you can always and forever know for sure that the last statement in any function is what it returns. Pattern matching does typically take most of the edge off that discomfort though. The biggest hurdle is getting comfortable with it all; when I first learned erlang my brain felt broken 2-3 weeks until it clicked, then it felt surprisingly natural and ergonomic.
It's started clicking for me slowly. I'm enjoying it greatly
You only really want to do an early return in two cases i can think of. One is to break out of a loop early, which gleam doesnt have any loops so no need there. Or another is some special condition is met, where you want to return something before going on to do other things. That is covered by pattern matching as others have said. In functional programming in general, you want to try to make your functions as small / simple as possible, and compose them from other functions. So you typically wont run into a problem where you wish you could use an early return, because the function is so small anyways.
And regarding deep nesting issues, you can usually use monads to "short circuit" a complicated tree of code paths into a single linear path. Sorry to use the word monad there as if you are new to FP it is just going to send you down an annoying, but hopefully interesting, rabbit hole. But the main idea is to think of it as short circuiting in this case. Like, do thing A that might return a result or an error (edge case), and then push that result if it exists into a function to do things with that valid result, otherwise just return the error / bubble it up. Usually the errors that are bubbled up are dealt with at the top of the call stack
Gleam are such amazing!
Agreed!
I hope it either sets up a trampoline or outputs loops for it's recursion when compiling to JS.
What do you mean by a trampoline?
Gleam looks awesome. Only thing i hate is lack of early returns. Can easily cause nesting hell
You can still get nesting hell with early returns 😅 you just have a different way of dealing with it. With functional languages, you use case statements and more functions
I really like type Inference but parameter and return type of a function should not be optional a function signature should tell you what the function does without the need to read the body.
The LSP will tell you :)
i know other functional languages have it, but pattern matching against multiple variables at once always makes me think of COBOL :)
i'll take a look at the concurrency model of erlang/beam/gleam. i hope it's ok. i'm starting to worry that go has spoiled me for every other language here .
You'll find it very similar! Like in Go, you don't have to deal with function colouring, you can spawn short lived or long lived tasks, etc.. Take a look at my concurrency video and let me know what you think
@@IsaacHarrisHolt ok, thanks for the video. for me i really like your pacing and the way you build things up to include real-world scenarios.
in my opinion the number of functions for dealing with concurrency in gleam/beam is just huge. i also haven't seen a way to organize shutting down of actors. this is one of the things go makes trivial with close(chan) which will cause all listeners to exit their foreach(chan) loops. the way i see it, go offers more functionality with fewer primitives.
i imagine i *could* learn to do concurrency with gleam/beam, but i'd be unsure how to build up a dag and then cleanly power it down, for example.
This is a fair point - it's a lot to learn, but in exchange you get a very powerful concurrency model that doesn't have all the same footguns as Go channels (which, sadly, do ruin the experience sometimes).
In terms of closing an actor, you'd just have a Shutdown variant of your message that the actor handles by returning an actor.stop() (I think that's what it's called). It's ultimately very similar to closing a channel except you don't have the extra function.
@@IsaacHarrisHolt yep, one needs to know best practices for concurrency in go. Though it's related to best practices in any language with mutable state, I think.
The advantage of close for go channels is that it disconnects all listeners, not just one.
That's true! Don't get me wrong, I love Go 😁
Can you do Grain next?
I've not heard of it! Sell me on Grain
Something wrong at 1:55 on line 4.
Assigning the string "Skyrim" to a variable named best_game should result in an unbiasedBadTaste error
I appreciate the effort you went through for this burn.
Unfortunately my response hit a 451 error when trying to upload to RUclips.
Fair enough
No install info on Linux 💀
You can use Homebrew, or it's available on a lot of the package managers
Gleam package is available on the AUR
@justy1337 Linux users does not need install instructions 🙂
There's some Linux instructions here: gleam.run/getting-started/installing/
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 😬
Take a look at the Wisp library written by Louis Pilfold. It's a webserver framework for Gleam
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.
I don't (yet)! But I'd recommend taking a look at the Gleam tour (tour.gleam.run) which covers pretty much all of this
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!
Take a look at my isaacharrisholt/youtube repo! There's a PR there for an upcoming Gleam video.
It's my first time writing Gleam/FP though, so it's not perfect yet
@@IsaacHarrisHolt thanks so much i'll check it out! and looking forward to more videos :)!
@@AbdolaMike Thanks!
If only I knew I could have just not added things like return I might have finished my scripting language lmao.
I think a scripting language probably needs early returns 😅 but valid
I love to see functional programming leaking into javascript dev land :P
Honestly anything is an improvement over JavaScript
We need something in production to run with Gleam
Yes! Please build for prod. Gleam is ready for it, are you 👀
@@IsaacHarrisHolt haven’t seen any examples, or any big companies using it in production. A bit risky imo
@@aleksd286 because it's only recently become production ready. People are starting to move to it
Never got to looking into Gleam. It seems to me like dumbed Erlang. Looks more JS-like for sure, but I'm not sure what the benefits are and if they are worth the cuts. Elixir adds to Erlang, this... seems to kinda make it JS compatible. I.e. looks like lowest common denominator situation to me. Yeah explicit types and stuff and corporate setting development, but that' like Scrum of a programming language.
Gleam adds static typing, mostly. It's 100% Erlang-compatible otherwise, and you get all the great features of the BEAM VM.
But yes, there's some stuff Elixir adds that Gleam can't.
I find it unnecessarily complicated not having if/else or loop. Would improve readability and dx.
For loops are practically pointless in a language like Gleam where data is immutable. It's very common for functional programming languages (like Gleam, Erlang, Elixir, Haskell) not to have loops for this reason.
As for if/else statements, one of Gleam's biggest values is simplicity. Since if/else can be accomplished with a case statement (and should actually be more performant than long if/else if chains on the BEAM target), there's no reason to have if/else. The goal is to minimise the surface area of the language, effectively.
For example:
```
if cond {
func1()
} else {
func2()
}
```
becomes
```
case cond {
True -> func1()
False -> func2()
}
```
You can also match on multiple values in a case statement, and that tends to be easier to read than a long if/else with lots of boolean logic.
@@IsaacHarrisHoltThank you. Can "True" or "False" be replaced by functions?
Like:
if (isSomethingGood()) doAnotherThing();
Of course! The predicate can be any value you can match on:
```
case is_something_good() {
True -> do_another_thing()
False -> cry()
}
```
You can even match on strings etc.
```
case name {
"Isaac" -> do_something()
"Ernst" -> do_something_else()
_ -> panic as "Unknown name!"
}
```
Great video! What did you use to make the video?
Obsidian!
Can't tell whether this looks like more convenient Haskell or less convenient Haskell, lol
It's Haskell that you can actually use in production
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.
I understand the reasoning, but since they're running primarily on the BEAM anyway, allowing FFIs gives access to the incredible Erlang ecosystem. It's also the primary reason they're able to use OTP APIs for concurrency (more in my next video!) and fault tolerant, scalable systems.
It was all fun and games, but you lost me on "gleam does not uses parenthesis to determine order of operation"
It uses blocks! It's just a different symbol, ultimately
Came to elixir and keep your heart on it
Not a Gleam fan?
@@IsaacHarrisHolt
No it is awesome language but i prefer elixir
Fair!
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 😂
The reason there's no networking in the stdlib is because of Gleam's multiple targets. The networking layer looks different depending on whether you're on Erlang or JavaScript.
There are first party networking libs available though that already do the referencing for you: gleam_httpc for Erlang and gleam_fetch for JS.
As for using FFI yourself, it's covered in the Gleam tour! tour.gleam.run
@@IsaacHarrisHolt ayee thanks for the reply, sure ill take a look myself! Great vids btw 👍
@@JohnDoe-np7do Thank you!
i would love a deeper Gleam video
Awesome! What sort of stuff would you like to see?
@@IsaacHarrisHolt I would really like to hear about what its MOST optimized for and what niche (if any) you think it will be adopted by.
What type of projects do you think will Gleam be chosen for?
Do you think it will be a general purpose language? Or be utilized exclusively by a whole industry like Elixir and Erlang have with Telecom?
What does it do well and not so well?
This is the first opportunity Ive had to try a brand new language and im kinda excited to try it
Interesting! I think Gleam's path is yet to be set, to be honest. Telecoms is probably going to adopt it at some point given it runs on the BEAM, but it's also got potential uses in web development and other areas.
Honestly I can't predict the future, and it's still a very young language. I think the community will shape the language a lot in the coming years.
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.
That's totally fair. There are very good reasons for all of these, but there are equally good reasons for not doing them, so I definitely see your point.
The last one, concatenation, is so that Gleam can infer when something needs to be a string over an int, float etc. and can therefore keep things statically-typed without needing to have type annotations everywhere
2:21 I am not thrilled that x/0===0 that sounds pretty risky to not check for that
There's a stdlib function that returns a Result if you need it :)
@@IsaacHarrisHolt okay that sounds alright
No loops except by recursion? How deep is the call stack? Seems like it will be hard to do an infinite loop unless you also have infinite ram to store all the return addresses
There's tail call optimisation, which keeps the call stack nice and light. Also, the BEAM is made to handle this sort of thing, so it can go pretty deep pretty efficiently
@@IsaacHarrisHolt how do you optimise the storage of infinite data though?
I'd recommend having a Google and researching BEAM recursion :)
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.
Elixir developer here, pattern matching is addictive… so much so that I forgot how to code without it
Pattern matching is great. Gleam's is a little restricted compared to some other languages, but a lot of that is because of the immutability
You can match mutiple values at once separated by comma. And wildcard any one or more. And assign the matches to a local const var easily. And qualify the match with an if guard. It's incredible.
It is pretty good, but I do wish you could do more complex string matching. For example, I'd love to be able to extract values without having to do regex:
```
case log_line {
"[" level "]: " message -> ...
_ -> ...
}
```
Same with lists - you can only match on the beginning of the list (though I understand the performance implications for both of these).
@@alexnoman1498And what about nested conditionals? Can it be done with pattern matching as well?
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.
Gleam (and other BEAM VM languages) aren't performance focused. Using a single linked list makes sense when the list is immutable, and allows you to reduce memory usage by sharing the tail of the list across multiple variables etc.
If an array was used instead, there would have to be a lot of memory copying to get the same immutability
@@IsaacHarrisHolt Thanks for the answer, that finally makes sense, just surprised for such a decision when everyone else chasing speed and perfomance
Now this is what functional languages were supposed to be
Isn't it great? Let me know what you build with it!
The function returns the last expression???? Cuteness and that always ends the same way
Yep! It's how Rust works too. It's quite common in functional languages
@@IsaacHarrisHolt yep and that's why with Python not running all code ends bad too in these statements
@@IsaacHarrisHolt and specifically in functional this would be the worst feature ever. Imagine multiple returns? I mean my God what a bad thing to watch
Yeah it would be awful
there is no null but there is nill? there is no branching but i do see an "if" keyword wtf?
Nil is its own type, and can't be assigned to anything else. It's like () in Rust.
The if keyword is only for guards in pattern matching, and it's fairly common to not have branching in functional programming languages
No loops, can't return early, no if/else, non-standard math syntax... definitely will be a hard sell. It's difficult enough to get adoption of rust, nevermind that lol
You've just described a lot of FP langs. It's not a Gleam-only thing, and I implore you to try things first :)
What kind of stuff have you been building with Gleam? Have you put it in production for anything?
Personally, no. I've only known about it for about a week, but I'm loving it already! Fly.io use it in production though
if I’m not mistaken the gleam transpiles to erlang and Erlang runtime (beam) has been used by telecom companies for decades
@@harrynair1811 yeah i'm not worried about Erlang but sometimes issues with a language's ergonomics or other challenges don't really become apparent until you start building real stuff with it
If you're curious, join the Gleam Discord. There are loads of cool projects happening all the time in there
@SeanLazer apologies, I've just learned I may be wrong here. Apparently Fly are just the sponsor and might not use it in production. You can definitely deploy Gleam to Fly though, so there's nothing stopping you trying it for free/cheap!
Gleam sounds cool! Although i feel like defining 'x / 0 = 0' should be a crime
There's a good reason for it, and there's also a div method in the std lib that handles this case using the Result type :)
@@IsaacHarrisHolt i get how it might be good im some cases, its just that it fucks with pure math. I feel like this breaks at least 5 Axioms in the Field of Real Numbers under multiplication and addition.
@@IsaacHarrisHolt Also i think defining it to be +infinity would make more sense, regarding the limit of e.g. 1/x under x -> 0
Gleam doesn't have the concept of infinity, and this result is actually quite common for BEAM languages. It's about making sure things don't crash as much as possible
@@IsaacHarrisHolt :C
At 5:05 should the function be multiply_and_divide() in lines 9-13? If not, how did it get shortened to multiply()?
It probably should, yeah 😅
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?
That's right, yeah
@@IsaacHarrisHolt how do you let the user know which types a function expects without type annotation, and how does the function guarantee that it receives correct types without type annotation?
Gleam can infer the types from the operators and functions used. It's still 100% statically typed :)
External and internal parameter names? What is the point?
It means you can give things nice names that make sense externally when calling the function and then a different one for use within the function body. There are some good examples in the standard library
Gleam is the closest language to perfect that I can find.
It's great! And the fact it runs on the BEAM makes it even greater
personally im sticking with c++, still cool though
They solve totally different problems, so that's fair!
Hollup an array is linked list in gleam? Why tho?
Easier for immutability, I think. You'd have to ask the Erlang folk
Rust with a GC
A little, yeah!
(Gleam complier is written in Rust)
Yes, it is! It was definitely inspired in some places
Not entirely wrong though Gleam's pattern matching (erlang's really) is far more powerful than rust's, as nice as rust's is.
Oh no. Division by 0 is zero.
What could possibly go wrong?
There's a standard library function that returns a Result :)
6:48 typo Andrew -> Mr Clark
You're right, thank you!
Someone pythonified my rust D:
At least there's no significant whitespace!
*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.
I don't know how you'd go about implementing a doubly linked list - there's probably a way, but it might involve writing Erlang instead.
But I'm glad you like Gleam :)
@@IsaacHarrisHolt I was actually looking at an erlang implementation when you commented. Thanks.
No worries!
i don't like indent of 2 spaces, how do i change it to tab size 4? in gleam, it is automatically on save formatting to 2 spaces
That's just the way the Gleam formatter is
@@IsaacHarrisHolt well that's a bad news
You'll get used to it as you write more Gleam :)
From the first glance of syntax, it seems extremely similar to F#
It's a functional language like F#, so it's a little similar for sure :)
But I'm wondering why/what problem gleam can but others can't solve?
There are pretty much no programming languages that can solve a problem that C can't solve. Silly argument, categorically.
At the moment, the biggest one is type safety on the BEAM. It's also similar enough to C-like languages that it acts as a nice intro to FP for people
spaceship operator
Oooh I love that! The UFO 👀
do Odin next ❤
On the list!
Not having loops is just an alien concept to me.
Yeah, having never written in a functional language before, it's a little tricky to get your head around first time.
Iterative loops are usually implemented in functional languages as map/fold/reduce/accumulate and the likes.
The body inside the "for" is given as a function which returns the result and and the state for the next iteration.
Example in pseudo code.
Instead of:
sum = 0
for item in list:
sum += item
You have:
sum = fold(list, 0, fn(cur, state) { cur + state })
Absolutely! And Gleam provides all of these
I mean if you think about it a for and while loop is just a recursive call after a comparison. “If this condition isn’t met do this again”.. The only difference is recursion is wrapped inside its own function. And functional languages use function overloading so you have a base case function and a recursive case function.
I don't know any coding yet I'm watching this. I have a problem. And his name is the Primeagen.
I understand your plight
Yeah, I watch him and get recommended all these coding videos :) Gleam does look cool, but my mind goes dead beyond basic HTML :D@@IsaacHarrisHolt
Hahahah well there are some great places to learn! Definitely an amazing skill to have
Looking at backend benchmarks, every single language on beam vm is very slow, like slower than php slow
In single-threaded benchmarks perhaps, but the strength of the BEAM is how easy it makes concurrency
When was the last time you checked your php speed? Versions 7 & 8 brought great speed gains.
BEAM was originally purpose built for high reliability and concurrency in critical telecom infrastructure, it deliberately trades raw speed to achieve this but it is generally considered *at least* fast enough for most use cases where its qualities are desirable. The success of tools like RabbitMQ and EjabberD at massive scale demonstrate this.
Wait… division by zero is zero? Omfg
There's a good reason! I recommend googling it
I'd say it's Golang and Elixir snob child
It does feel a lot like Go! I've not written Elixir though, so I can't comment on that
I was excited until i saw recursion and then remembered my beef with erlang
It's common to use recursion in a lot of functional languages. It makes sense here where values are immutable
@@IsaacHarrisHolt idk my brain is just too dumb to structure recursive functions correctly. Skill issue, I know, I just like my for loops that's all
@@formyeve Don't do recursion directly.
For most things, a map/fold/reduce/accumulate etc is more than enough.
You only need custom recursion in rare cases.
This is true. I write JS/TS for a living and honestly I rarely find myself using for loops
im thinking about just not writing anymore code anymore except for gleam and its entirely your fault
I meannnn, sounds like a win to me 😉
@@IsaacHarrisHolt actually I also wanted to know, from my understanding gleam is interpreted and can transpile into js right?
Gleam compiles to either JS or Erlang, which both get compiled to bytecode and executed by their respective VMs
Can you make Linux commands for impatient devs pls?
Oooh interesting! That'd probably be really useful for me too, tbh
@@IsaacHarrisHoltthanks Isaac
I am missing UFCS, but cool language
Fair, but you can achieve the same thing with the pipe operator most of the time. Gleam doesn't support any form of methods on types