The Death of Tagless Final by John A. De Goes

Final tagless. The topic strikes fear into the hearts of Scala developers everywhere-and not without reason. Final tagless allows developers to build composable Domain Specific Languages (DSLs) that model interaction with the outside world. Programs written using the final tagless style can be tested deterministically and reasoned about at compile-time. Yet the technique requires confusing, compiler-choking higher-kinded types, like `F[_]`, and pervasive, non-inferable context bounds like `F[_]: Concurrent: Console: Logging`. Many have looked at final tagless and wondered if all the layers of complexity and ceremony are really worth the benefits.
In this presentation, John A. De Goes provides a gentle and accessible introduction to final tagless, explaining what it is and the problem it intends to solve. John shows that while final tagless is easier to use than free monads, the technique suffers from a litany of drawbacks that push developers away from functional programming in Scala. John then introduces a novel approach that shares some of the benefits of final tagless, but which is idiomatic Scala, easy to explain, doesn’t need any complex type machinery, provides flawless type inference, and works beautifully across Scala 2.x and Scala 3.
Come join John for an evening of fun as you learn how to write functional code in Scala that's easy to test and easy to reason about-all without the complexity of free monads or final tagless.

[@QRIOART]

Who is this amazing, charismatic force of nature? Awesome talk!!! 🌞🖖🏽😌

[@ZelenoJabko]

You gheiii?

[@QRIOART]

@@ZelenoJabko YES! And Yes! and yaaaaassss bitch!

[@QRIOART]

And I know the speaker personally. Thank you.

[@ZelenoJabko]

@@QRIOART awesome!!

[@tepan]

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

[@matroska80]

Eventually someone recorded it!

[@ArturSukhenko]

Thanks.

[@YanDoroshenko]

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.

[@MadPengie]

Thank you! Really interesting and impressive. I need to relearn how to program.

[@isarwarfp]

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 ?

[@kaktusdono]

My bald angel

[@ZelenoJabko]

ZIO seems amazing, he is a great salesman. However, what are the disadvantages?

[@guillemgarcia3630]

incomprehensible and too much abstracted code. Luckily someday the septifunctor will come to abstract our minds away.

[@nikitamyazin6586]

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.

[@xbmarx]

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.

[@georgH]

Wow, that's wonderful. Is there anything similar for haskell? Especially in terms of low boilerplate, high performance and full inference

[@CarlosSaltos]

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

[@LL-ol8gr]

The start 6:00

[@TJ-hs1qm]

14:31 Reason why call by name style X: => A works for methods within Objects but not within case classes kzbin.info/www/bejne/raS3epZ-ra-Am7M