Gleam for Impatient Devs
Vložit
- čas přidán 3. 06. 2024
- 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:
polar.sh/isaacharrisholt
Resources:
Gleam: gleam.run
Gleam Language Tour: tour.gleam.run
Standard library documentation: hexdocs.pm/gleam_stdlib
__________________________________________
Check out my other socials!
🎮 Discord ▶ discordapp.com/invite/bWrctJ7
🐦 Twitter ▶ / isaacharrisholt
🖥️ Portfolio ▶ ihh.dev
📝 Blog ▶ polar.sh/isaacharrisholt
__________________________________________
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 - Věda a technologie
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 :)
small mistake at 3:23, Gleam list are homogeneous, not heterogeneous
You're right, thank you! I always get those confused
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!
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!
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 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!
Gleam seems really neat. I'm excited about it. Thanks for covering it!
Let me know what you build!
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
Great video, covered all of the main points of interest.
Thanks! Glad you found it useful
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 :)
More Gleam content is something I dream of in 2024!
On it!
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
Thank you. I love Gleam and its syntax, which looks similar to Rust.
It's great!
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
Love your fast-paced content, just subscribed
Thank you!
Hope the `use value
Elixir has "with x
Interesting!
Roc has a similar thing called backpassing
@@kilianvounckx9904 good to know! Roc looks really interesting
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!
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
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
Well this looks just lovely.
It is! The people are great too
It looks amazing! Like a Rust for humans without tons of syntax garbage. I wish the language to prosper!
It's great!
Great video! What did you use to make the video?
Obsidian!
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 😅
yes, more Gleam, please!
Working on it!
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.
*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!
Please more gleam videos!
On it!
Gleam looks like a very cool language!
It is! I recommend checking it out
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
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
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?
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
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
Gleam are such amazing!
Agreed!
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.
Não tenho certeza se isso é algo em que posso ajudar. Sou engenheiro de software
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 :)
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!
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!
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.
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 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 :)
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!
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!
But is it BLAZINGLY fast?
Not particularly - BEAM languages are better for fault tolerance and concurrency than raw speed
Can you do Grain next?
I've not heard of it! Sell me on Grain
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
I love to see functional programming leaking into javascript dev land :P
Honestly anything is an improvement over JavaScript
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
do Odin next ❤
On the list!
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.
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
Came to elixir and keep your heart on it
Not a Gleam fan?
@@IsaacHarrisHolt
No it is awesome language but i prefer elixir
Fair!
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
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 CZcams.
Fair enough
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
Now this is what functional languages were supposed to be
Isn't it great? Let me know what you build with it!
6:48 typo Andrew -> Mr Clark
You're right, thank you!
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.
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
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
Some Gleam's features remind me Ada.
Ooh interesting, I've never written Ada. What's the similarity?
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/
It's OcamL with brackets
And better tooling 😉
Can you make Linux commands for impatient devs pls?
Oooh interesting! That'd probably be really useful for me too, tbh
@@IsaacHarrisHoltthanks Isaac
2:31 Why is that needed?
It's so that Gleam can infer when something should be a Float!
@@IsaacHarrisHoltThat relates to the result? Would 1.0 + 1.5 give an error or be 2 or 3?
1.0 + 1.5 would give a compile error
1.0 +. 1.5 would give 2.5
@@IsaacHarrisHoltThan I'm too dumb to understand, why does it need to infer type from the operator rather than the values?
1 + 2.0 would give an error but 1 +. 2 is fine and be 3.0?
What's the underlying thought behind a special operator "because you are adding floats instead of ints"?
Is the compiler handling the operation differently?
Consider the following function:
```
fn add(a, b) {
a + b
}
```
If the same operator was used for both, the compiler wouldn't know the types of `a` and `b` here. However, if we only use `+` for `Int` values, then the compiler knows `a` and `b` must both be integers. This way we don't need type annotations everywhere
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.
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
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
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
Someone pythonified my rust D:
At least there's no significant whitespace!
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
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
spaceship operator
Oooh I love that! The UFO 👀
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.
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
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.
seems to be mix between typescript and python :)
Interesting! That's a new one. I think Gleam matches up with a lot of languages
@@IsaacHarrisHolt yeah but the syntax look like typescript alot and the Camel case of types and boolean from python :D this why i said that
Gotcha!
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!"
}
```
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 would argue that Gleam always tells you what's going on. There's little to no magic
@@IsaacHarrisHoltThere are no nulltypes in Gleam. The error handling looks very similar to Rust. It also has strong similarities to Rust in terms of syntax. There are differences to Rust. Wasn't Gleam a real dynamically typed programming language?
Gleam is statically typed :)
@@IsaacHarrisHolt I truly need to check again, what are the differences between rust and gleam.
Gleam is a functional language, so values are always immutable, and there are no such thing as methods. It also runs on the BEAM VM rather than compiling to native code
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.
Oh no. Division by 0 is zero.
What could possibly go wrong?
There's a standard library function that returns a Result :)
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
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
"Lists are heterogeneous" ... wait. what?
EDIT: oh it was just a mistake that you acknowledged below. phew
Yeah sorry 'bout that 😅
How is something divided by 0 equal to 0 💀💀
It ensures the program never panics! It's a good tradeoff, I think. If you need 0 to be an invalid divisor, you can check it yourself and handle it that way
Lists are homogeneous. Tuples are heterogenous.
Yep! You're right, thanks :)
This looks a lot like rescript
A little, yeah! I prefer Gleam personally. I find the syntax more familiar, but I do see the benefits of ReScript
@@IsaacHarrisHolt yeah, I see how gleam is a bit more terse. However, they are making some of the same mistakes rescript did and even some of the ones they did when they were reasonml
@@Danielo515 interesting! What mistakes do you think those are?
@@IsaacHarrisHolt The lack of return keyword is one of them. Sure, having implicit returns is very nice, but having early returns really reduces complexity. Also the way they define type generics. Using parenthesis may look cooler, but makes it a lot harder to differentiate runnable code from just type definitions. There is a reason why most languages have settled in
The lack of early returns is very common in functional languages, and Gleam kinda gives you a way to emulate early returns by using:
`use _
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...
It runs on the BEAM, which is the most fault-tolerant platform out there. Also, you can deploy it on Fly.io, so there's no reason you can't try it in production and test it yourself :)
@@IsaacHarrisHolt i don't want to test it thanks. i know how it works but to claim all those claims while it's still in beta it's stupid. Rust had all those claims from the start and barely started to become usable in 2022 and broke backwards compatibility a million times to the point I don't care about it anymore
It's not in beta! They've just released V1 of the language. I think to make comments like this without even being willing to give the language a shot is a little short-sighted.
I don't get it. Why have different operators for floats?
That way the compiler knows when a value is supposed to be a float without you having to write type annotations
"Has Nil"
"No null or undefined"
I don't think that's quite accurate
Typically, null and undefined can be applied to any value. In Gleam, Nil is equivalent to () in Rust, and is only ever Nil.
Nil can never sneak up on you. Null can. Massive difference. The typechecker reminds you whether something returns only ever Nil or something else that can never ever be null.
Absolutely! And you can use `Option` or `Result(_, Nil)` (which is how the Gleam stdlib does it) if you want optionality
Can zoomers use this language?
Not unless emojis can be used for variable names.
Absolutely! Very zoomer-friendly
please, compile to native instead of just beam
It can also transpile to JavaScript! Compiling to native would be a loooot of work. A lot of the Gleam standard library requires the underlying Erlang/JS functions and there's a lot of FFI going on
Ugh... It enforces snake case...
Yep! Your code will forever be readable
@@IsaacHarrisHolt I understand your love for snake case readability, but also really dislike using underscores, so uncomfortable. I know I can remap it to faster key combinations, but I'd have to do that for every machine I work on and I won't be able to do that if I'm using a shared or lent one.
True, but how often do you use a shared machine? You spend more time reading code than writing it, so I personally think the tradeoff is worth it regardless
@@IsaacHarrisHolt I think it should be a matter of choice.
Fair, but many modern languages will enforce one way or another. Personally, I think it's better to be consistent.
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
No instructions for Linux, despite it being popular among developers.
You can install via Homebrew :)
@@IsaacHarrisHolt isn't homebrew for Mac? I'm confused.
It's for Mac and Linux. Plus, there's quite a few Linux distros mentioned here: gleam.run/getting-started/installing/
@@IsaacHarrisHolt cool.
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
You can use the divide functions in the stdlib to get a Result that handles zero division errors.
And I appreciate the self-awareness 😂
@@IsaacHarrisHolt well at least there's that, so that's good. Still don't like the default functionality, but hey, when errors occur the blame can be shifted to the programmer for not checking if denom == 0
I think it's actually quite common behaviour for BEAM languages to ensure they don't just crash
division by zero = zero is bs
There are good reasons for it, and ways to make division return a result. Check out other comment threads here for more info :)
Idk, just use Elixir? Much more mature and better
"Better" is always subjective. Gleam can use Elixir libraries, so the ecosystem maturity argument doesn't really work either. I think Gleam's strengths are the type system and how similar it feels to lots of C-like languages, which lowers the barrier to entry for non-FP devs
I love Elixir, but I never loved the lack of types. BEAM with types is 🎉