ERRATA: 05:43 - The fan out line should read `|> list.map(fn(email) { task.async(send_email(email)) })`. It's missing the `task.await`! Thanks @josephlyons3393 for pointing this out
Gleam has been my introduction to the BEAM and a lot of functional concepts, and video's like this help SO MUCH! Trying to see problems through a non-Object-Oriented lens has been interesting, and a lot of your videos have been very useful and easy to understand. Thanks for the time you put into making your content.
@@IsaacHarrisHolt I'm currently doing a larger personal project in Go and I'm trying to actually get it done and avoid the shiny object syndrome. I'm still not sold on whether I should look into Gleam or Elixir next, but your videos are very clean and convincing
@@abuk95 I just commented on this particular video. More so due to the syntax than the the concurrency model. But in AoC I did solve some problems with concurrency (probably should have used a better algorithm though)
I think you need to slow down a bit because I can't keep up. I barely have time to read the code between each slide, and on top of that I need to also listen to what you are saying and then find the piece of the code you mean. It's interesting and all, but at some point I started to zone out because it just became a stream of words... "To start the supervisor call supervisor start and the supervisor starts and returns a supervisor subject that ..." I'll rewatch again later to see of it sticks better that time.
I have the exact same issue, i think maybe keeping the whole block shown while just highlighting the part you are talking about might do the trick. And yes i guess slowing down a but may also decrease the "stream of words" effect
I hope it didn't come off as too harsh. I enjoyed the content, and your enthusiasm for the content really makes me want to learn too! I'm subscribed now and look forward to the next installment!
Thank you! And not harsh at all, don't worry! It's fairly common feedback, but I also get a lot of feedback from people who find the quick pace refreshing
Great video! I've been wanting a video on exactly this - thank you! Also, small thing, but at 5:51, you can shorten the code a tiny bit with `list.map(send_email)` and skip the anonymous function wrapper.
You're right! But mostly because I actually made a mistake on that line and it should read `|> list.map(fn(email) { task.async(send_email(email)) })` (wrapped with `task.async`)
What's nice about Gleam is that you don't really need microservices! Most of the benefits you get from them, like asynchronous operations and easy scaling, are already taken care of by the BEAM VM
Well, that's a tough one :) I'll come back after diving into the Learn OTP w/Gleam repo and the docs. p.s. why the code highlighting is so weak?. Just copy paste from the vscode and you'll get the colors!
Awesome! And the code highlighting isn't great because Gleam isn't supported by the library used yet. I use vim and copying the text from there doesn't copy the colours, so sadly that doesn't work!
@@IsaacHarrisHolt hi! 7:33 - 8:12 I don't really understand why actor.call() works when we pass to it a record of "type Message" as a second argument, while the second argument of actor.call() must be a "fn(Subject(b)) -> a"... but it works and even can pass additional message record's arguments... p.s. record of the Message is treated as a function?.. still don't get it. p.s.s. Ok so we are using a function capture to capture the message constructor and if need we pass the additional arguments so the only thing to pass to a constructor left is a new subject which will be added automatically (so we write placeholder) and will be used to send the result to a client. And the result type is declared by the type of reply_with: Subject(***) field of the Message record. p.s.s.s hmmm seems I got it, don't I? brain hurts :()()()( Your video was really helpful to bring all the info about the actors together... I would like to believe :)
@@IsaacHarrisHolt Yo! As expected, your video was very useful. After and while reading the repo and the documentation, it helped a lot to understand what was going on. Especially in trying to understand how the whole actor loop works (Message type, handler, actor.send, actor.call). Thanks a lot!
Nice video. I believe I understand the concurrency model from this and other content, but I struggle to find project ideas where I can make effective use of it. Any good ideas for putting these into action?
It'll depend on the project, but you can use tasks for asynchronously interacting with APIs or running other background jobs. Actors are good for queued work or holding shared state
The build your own redis challenge is free this month on codecrafters in Gleam :) it uses the glisten tcp server, which is built on gleam_otp and uses gleam actors in it's APIs. It's a fun practical use case, plus because BEAM concurrency is really good you pass the first three stages just by setting up the server, it's pretty neat. If you get stuck, Louis (the gleam language author) streamed some videos doing the challenge on twitch and youtube.
@@IsaacHarrisHolt i am also amazed by wathing louis pilfold 1hr video making backend with gleam, then your video dropped out at the perfect time lol. damn, the syntax is really neat 👌
Gleam seems promising, but honestly, these days I have been wondering, why people seem keen on performance? I don't get it. Even the most famous youtubers at most get 1000 views per second, which is much less than what python slowest framework can handle. You have caches, algorithms, etc... all of which could speed up the framework even more. So it's really pointless. I would use gleam only if there's a benefit that I don't get with python, otherwise, I won't jump ship.
Gleam doesn't really give you much performance over Python. What it does give you is reliability. With Python, if one of those 1000 requests per second crashes (not with an exception, but properly crashes), every other request in flight being handled by that instance would fail. With Gleam and other BEAM languages, if one request crashes (e.g. with a panic, like in the video), only the process handling that request goes down. The rest of the application can continue. Also, the BEAM makes it nearly trivial to distribute across multiple machines in multiple regions, so you can easily keep serving traffic if a whole data centre goes down. Python and other languages need additional overheard like orchestration tools to make that happen.
The beam vm allows you a completely different paradigm that is very suited to the web. Like OP says, you can crash a process without affecting everything else. Also from experience with elixir, you don't need to bring in extra libraries, servers and languages to do web things. You don't have to reach for redis, nginx, managing cron and bash scripts, crash recovery with upstart... you don't have to orchestrate all these things across many languages, it's all baked in with OTP.
PLEASE, DON'T SELL AN GLEAM COURSE LIKE THE OTHERS, I'M NEED GET MY LUNCH. For a more democratic web with easy access to technology, that people can change their lives for the better.
Don't worry! If I do ever make a Gleam course, it won't have any information that isn't available elsewhere on my channel - it'll just be more structured.
ERRATA:
05:43 - The fan out line should read `|> list.map(fn(email) { task.async(send_email(email)) })`. It's missing the `task.await`! Thanks @josephlyons3393 for pointing this out
Please! More Gleam content of this quality and clarity. It's awesome, thank you!
Absolutely! Working on it :)
@@IsaacHarrisHolt I'm excited!
Lustre next! Hayleigh is gonna be very pleased
Gleam has been my introduction to the BEAM and a lot of functional concepts, and video's like this help SO MUCH! Trying to see problems through a non-Object-Oriented lens has been interesting, and a lot of your videos have been very useful and easy to understand. Thanks for the time you put into making your content.
I'm just really glad I'm able to be helpful! Thanks so much :)
Gleam is looking more and more like my next Advent of Code language
Sounds good, but why wait until December 👀 and why not try it out on some real projects?
@@IsaacHarrisHolt I'm currently doing a larger personal project in Go and I'm trying to actually get it done and avoid the shiny object syndrome.
I'm still not sold on whether I should look into Gleam or Elixir next, but your videos are very clean and convincing
Fair enough! Good luck with the project :)
Why? You don't need more than one process for AoC
@@abuk95 I just commented on this particular video. More so due to the syntax than the the concurrency model. But in AoC I did solve some problems with concurrency (probably should have used a better algorithm though)
"if the supervisor can't restart its child for whatever reason, it will kill its other children, and then itself" 🤣🤣
Sounds like a, uh, pretty normal Sunday to me
Another great gleam video. Everytime, I wanna learn and use gleam more.
Do it! It's a great language. I'll be doing more Gleam tutorials in the future too :)
I think you need to slow down a bit because I can't keep up. I barely have time to read the code between each slide, and on top of that I need to also listen to what you are saying and then find the piece of the code you mean.
It's interesting and all, but at some point I started to zone out because it just became a stream of words... "To start the supervisor call supervisor start and the supervisor starts and returns a supervisor subject that ..."
I'll rewatch again later to see of it sticks better that time.
Understood! Thanks for the feedback
I have the exact same issue, i think maybe keeping the whole block shown while just highlighting the part you are talking about might do the trick. And yes i guess slowing down a but may also decrease the "stream of words" effect
I do try and highlight where possible! Sometimes that's more difficult though, but I'll do my best :)
I hope it didn't come off as too harsh. I enjoyed the content, and your enthusiasm for the content really makes me want to learn too!
I'm subscribed now and look forward to the next installment!
Thank you! And not harsh at all, don't worry! It's fairly common feedback, but I also get a lot of feedback from people who find the quick pace refreshing
Great video! I've been wanting a video on exactly this - thank you! Also, small thing, but at 5:51, you can shorten the code a tiny bit with `list.map(send_email)` and skip the anonymous function wrapper.
You're right! But mostly because I actually made a mistake on that line and it should read `|> list.map(fn(email) { task.async(send_email(email)) })` (wrapped with `task.async`)
Time to make Isaac head of GleamVideo
I believe the official term is The Glambassador
@@IsaacHarrisHolt I knew you were the right person for the job
@lpil thanks for your hard work an this amazing language :)
@@andredasilva6807 thank you!
keep up thr amazing gleam videos. i started using gleam and its amazing. the lsp need some work, but its on its way to be a fantastic language
Thank you! I've got more in the works, don't worry
Another good Gleam video,
Thanks Isaac
Thank you! I hope you found it helpful
Hi Issac, would love to see a tutorial on REST API CRUD with authentication and SQL DB
I'll be looking into this sort of thing with Wisp at some point in the future!
I really love gleam, the tasks to avoid function coloring *MUAH, beautiful
Best feature of Gleam tbh
man, i always loved erlang, its syntax, and its concurrency, but never used it on prod. This looks so promising!
It's fun! And very easy to do, too
Gleam looks like a nice language to write some microservices in 👌
What's nice about Gleam is that you don't really need microservices! Most of the benefits you get from them, like asynchronous operations and easy scaling, are already taken care of by the BEAM VM
Well, that's a tough one :)
I'll come back after diving into the Learn OTP w/Gleam repo and the docs.
p.s. why the code highlighting is so weak?. Just copy paste from the vscode and you'll get the colors!
Awesome!
And the code highlighting isn't great because Gleam isn't supported by the library used yet. I use vim and copying the text from there doesn't copy the colours, so sadly that doesn't work!
@@IsaacHarrisHolt hi!
7:33 - 8:12
I don't really understand why actor.call() works when we pass to it a record of "type Message" as a second argument, while the second argument of actor.call() must be a "fn(Subject(b)) -> a"... but it works and even can pass additional message record's arguments...
p.s. record of the Message is treated as a function?.. still don't get it.
p.s.s. Ok so we are using a function capture to capture the message constructor and if need we pass the additional arguments so the only thing to pass to a constructor left is a new subject which will be added automatically (so we write placeholder) and will be used to send the result to a client. And the result type is declared by the type of reply_with: Subject(***) field of the Message record.
p.s.s.s hmmm seems I got it, don't I? brain hurts :()()()( Your video was really helpful to bring all the info about the actors together... I would like to believe :)
@@IsaacHarrisHolt Yo! As expected, your video was very useful. After and while reading the repo and the documentation, it helped a lot to understand what was going on. Especially in trying to understand how the whole actor loop works (Message type, handler, actor.send, actor.call). Thanks a lot!
@@ryzh6544 nice one! I'm glad I was able to help
Do you use GenServers in Gleam? I'd love to see a video on that.
GenServers in Gleam are called actors! They're covered in detail here :)
This channel deserves a SUBSCRIBE!😉
Thank you!
Thanks the video I was wainting for
I hope you found it helpful!
Amazing video as usual.
Thank you, thank you!
Nice video. I believe I understand the concurrency model from this and other content, but I struggle to find project ideas where I can make effective use of it. Any good ideas for putting these into action?
It'll depend on the project, but you can use tasks for asynchronously interacting with APIs or running other background jobs. Actors are good for queued work or holding shared state
The build your own redis challenge is free this month on codecrafters in Gleam :) it uses the glisten tcp server, which is built on gleam_otp and uses gleam actors in it's APIs. It's a fun practical use case, plus because BEAM concurrency is really good you pass the first three stages just by setting up the server, it's pretty neat. If you get stuck, Louis (the gleam language author) streamed some videos doing the challenge on twitch and youtube.
Yes, this is a fantastic way to learn Gleam!
Awesome as always!
Thank you!
this is really similar with Akka Actor Model Approach
Interesting! I'm not a JVM person, but Akka looks cool
this language is beautiful
I know, right!
@@IsaacHarrisHolt i am also amazed by wathing louis pilfold 1hr video making backend with gleam, then your video dropped out at the perfect time lol. damn, the syntax is really neat 👌
@@devyb-cc awesome!
god i love this
Gleam is great!
Great Video!
Thank you!
Amazing video
Thank you! I hope you found it helpful :)
Great video, but please show the code snippets for a longer time before you switch to memes. The video is a little hard to follow at normal speed.
Understood! I've started slowing things down in my more recent videos :)
Gleam seems promising, but honestly, these days I have been wondering, why people seem keen on performance? I don't get it. Even the most famous youtubers at most get 1000 views per second, which is much less than what python slowest framework can handle. You have caches, algorithms, etc... all of which could speed up the framework even more.
So it's really pointless. I would use gleam only if there's a benefit that I don't get with python, otherwise, I won't jump ship.
Gleam doesn't really give you much performance over Python. What it does give you is reliability. With Python, if one of those 1000 requests per second crashes (not with an exception, but properly crashes), every other request in flight being handled by that instance would fail.
With Gleam and other BEAM languages, if one request crashes (e.g. with a panic, like in the video), only the process handling that request goes down. The rest of the application can continue.
Also, the BEAM makes it nearly trivial to distribute across multiple machines in multiple regions, so you can easily keep serving traffic if a whole data centre goes down. Python and other languages need additional overheard like orchestration tools to make that happen.
The beam vm allows you a completely different paradigm that is very suited to the web. Like OP says, you can crash a process without affecting everything else. Also from experience with elixir, you don't need to bring in extra libraries, servers and languages to do web things. You don't have to reach for redis, nginx, managing cron and bash scripts, crash recovery with upstart... you don't have to orchestrate all these things across many languages, it's all baked in with OTP.
@@rumble1925 thanks, i think having all in one experience could justify using it.
immutability and async just don't mix man. I want to mutate my state from 16 threads so much it's unreal
I'm reeeally hoping this is sarcastic 😅
@@IsaacHarrisHolt yeah it is... although lack of mutability isn't always a good thing
@@sunofabeach9424 agreed. It depends what you're trying to achieve
PLEASE, DON'T SELL AN GLEAM COURSE LIKE THE OTHERS, I'M NEED GET MY LUNCH. For a more democratic web with easy access to technology, that people can change their lives for the better.
Don't worry! If I do ever make a Gleam course, it won't have any information that isn't available elsewhere on my channel - it'll just be more structured.
@@IsaacHarrisHolt thanks a lot.