It's a great talk, and I enjoy it every time I watch the video again. About the Final Tagless (or Tagless Final) part: 28:32 "Type Classes don't exist in Scala." - OK, but that's not Tagless Final's fault, but Scala's. 29:35 "You also gotta understand the Monad hierarchy. Because in order to ... just do for-comprehensions, you need flat and flatMap, so you gonna need to understand Functor and Apply and Applicative and Bind and then of course Monad, and that's just the start." - One already got to understand the Monad hierarchy in order to understand for-comprehensions, don't they? 32:41 "There is no way to factor out that duplication." Again, Scala is to blame, not Tagless Final. 33:18 "Maybe there should be, but there is not." - (One could have mentioned Haskell here.) 34:34 "Because this is Scala." - Yup. :)
Question related with Implicit Parameter List (Everything), How about "modules" that Gabriel explained, adding all dependencies in respective modules and provide the related modules required by the function. Wouldn't decrease that implicit parameter list and make it close to Everything ?
If you provide a ZIO[R, _, _] an R, you get a ZIO that doesn't require anything. While type signature ZIO[Any, _, _] specifically indicates that it does, in fact, require anything.
Haskell is already a pure FP language ... Scala is not ... it’s Scala that need to copy from Haskell, no the other way around ... but anyway it’s nice to see Scala FP improve, I love Scala
I don't know why it was said that it's incomprehensible, I wonder which things for concurrent application are considered to be comprehensible in this case. The concept of an environment in ZIO still feels raw. It's often unclear which things you should put into the effect environment, and which things should be provided locally to not expose implementation details. Also, they have Zlayer thing (which will be renamed in ZIO 2) to build an environment which sounds good on paper but in practice it creates tons of boilerplate and makes it hard to glue everything. To be fair, there is a macro for that and it will be included in ZIO 2, but IMO it only shows that Zlayer is not meant for human usage :) So lack of good and bad practices (yet) and human friendly API for building an environment makes it a really questionable thing at least for me. However, the good thing about that is that you can just not use it at all. In this case, you'll still get great library that is much more comfortable to work with as compared to other effect systems in Scala / to Futures.
You lose the higher-kinded polymorphism of Tagless Final -- i.e. you are passing IO around _everywhere_. This is a tradeoff, it's not necessarily bad. You lose polymorphism (making things less ridiculously easy to test and extend) -- but you gain great abilities to manage dependencies and wire things together.
![YoungBoy Never Broke Again - Catch Me [Official Video]](http://i.ytimg.com/vi/KxwEXXFQMTY/mqdefault.jpg)
It's a great talk, and I enjoy it every time I watch the video again. About the Final Tagless (or Tagless Final) part:
28:32 "Type Classes don't exist in Scala." - OK, but that's not Tagless Final's fault, but Scala's.
29:35 "You also gotta understand the Monad hierarchy. Because in order to ... just do for-comprehensions, you need flat and flatMap, so you gonna need to understand Functor and Apply and Applicative and Bind and then of course Monad, and that's just the start." - One already got to understand the Monad hierarchy in order to understand for-comprehensions, don't they?
32:41 "There is no way to factor out that duplication." Again, Scala is to blame, not Tagless Final.
33:18 "Maybe there should be, but there is not." - (One could have mentioned Haskell here.)
34:34 "Because this is Scala." - Yup. :)
Who is this amazing, charismatic force of nature? Awesome talk!!! 🌞🖖🏽😌
You gheiii?
@@ZelenoJabko YES! And Yes! and yaaaaassss bitch!
And I know the speaker personally. Thank you.
@@QRIOART awesome!!
Thank you! Really interesting and impressive. I need to relearn how to program.
Eventually someone recorded it!
Thanks.
Question related with Implicit Parameter List (Everything),
How about "modules" that Gabriel explained, adding all dependencies in respective modules and provide the related modules required by the function. Wouldn't decrease that implicit parameter list and make it close to Everything ?
My bald angel
If you provide a ZIO[R, _, _] an R, you get a ZIO that doesn't require anything. While type signature ZIO[Any, _, _] specifically indicates that it does, in fact, require anything.
Wow, that's wonderful. Is there anything similar for haskell?
Especially in terms of low boilerplate, high performance and full inference
Haskell is already a pure FP language ... Scala is not ... it’s Scala that need to copy from Haskell, no the other way around ... but anyway it’s nice to see Scala FP improve, I love Scala
ZIO seems amazing, he is a great salesman. However, what are the disadvantages?
incomprehensible and too much abstracted code. Luckily someday the septifunctor will come to abstract our minds away.
I don't know why it was said that it's incomprehensible, I wonder which things for concurrent application are considered to be comprehensible in this case.
The concept of an environment in ZIO still feels raw. It's often unclear which things you should put into the effect environment, and which things should be provided locally to not expose implementation details. Also, they have Zlayer thing (which will be renamed in ZIO 2) to build an environment which sounds good on paper but in practice it creates tons of boilerplate and makes it hard to glue everything. To be fair, there is a macro for that and it will be included in ZIO 2, but IMO it only shows that Zlayer is not meant for human usage :) So lack of good and bad practices (yet) and human friendly API for building an environment makes it a really questionable thing at least for me. However, the good thing about that is that you can just not use it at all. In this case, you'll still get great library that is much more comfortable to work with as compared to other effect systems in Scala / to Futures.
You lose the higher-kinded polymorphism of Tagless Final -- i.e. you are passing IO around _everywhere_.
This is a tradeoff, it's not necessarily bad. You lose polymorphism (making things less ridiculously easy to test and extend) -- but you gain great abilities to manage dependencies and wire things together.
The start 6:00
14:31 Reason why call by name style X: => A
works for methods within Objects but not within case classes
ruclips.net/video/wsTIcHxJMeQ/видео.html