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
@@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)
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 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.
