Видео

What an excellent tutorial ! Can only come from a person who understands CS fundamental in depth .

Hey, I have noticed Kotlin videos on the channel are a thing recently and I am just curious if this signifies the decline of Scala popularity while Kotlin is growing? Or maybe you want to keep the channel open to a wider audience? Or maybe there are not many Scala libraries/topics that you want to present currently? Just curious?

Hello Daniel, I've recently found your videos and they've been a blast to go through so thanks for the effort put in. While watching the video I came up with different implementations for the < and <= traits, are there issues I'm not seeing atm? I've tested for every combination with the type aliases from 0 to 5 object < { given succLt[A <: Nat]: <[A, Succ[A]] = new <[A, Succ[A]] {} given chainedLt[A <: Nat, B <: Nat](using lt: <[A, B]): <[A, Succ[B]] = new <[A, Succ[B]] {} } object <= { given eq[A <: Nat]: <=[A, A] = new <=[A, A] {} given succLte[A <: Nat]: <=[A, Succ[A]] = new <=[A, Succ[A]] {} given chainedLte[A <: Nat, B <: Nat](using lt: <=[A, B]): <=[A, Succ[B]] = new <=[A, Succ[B]] {} }

Can we use spark with kotlin?

I love Scala, I really do. But at the risk of sounding like a hater - this solves an issue that nobody had a problem with. I have a mere 6 years of Scala under my belt and so far the companies I know that use Scala in production either do not use its full power OR (and worse) shifting away from it. It is hard enough to find a good Scala programmer, let alone an advanced one, so please, let's stop making things more complex. And to top it all, if I did understand the explanation well, it is not available in Scala 2 due to the lack of type matching which makes this feature a major block for most of the industry.

I mainly write rust, but scala, being arguably more open to different paradigms than rust, does functional programming so well. I really hope ergonomic HKT's will be added to rust one day.

Implicits in general should be used VERY sparingly. This works here but when you’re reading older code and they use them, it almost always turns out to not be worth it.

Unfortunately GROUP BY is not covered.

t.b.h. this all looks to me like just a good theoretical exercise, but in my daily work I wouldn't choose neither this nor ZIO-layers over the good old macwire "lazy val userSubscription = wire[UserSubscription]". And even if not relying on the macwire - then still I would rather wire everything manually "lazy val userSubscription = UserSubscription(userService, db)", than having to write those unnecessary layers/providers/etc

In my practice writing the wiring logic is the smallest possible problem. And the compiler helps me by checking the *explicit* types in the constructors. I don't see the benefit of the extra compiletime magic to get the same results. Generally I don't see the benefit of any magic at all.

_Looks at Scala history page_ : "Scala was designed to be a better Java" Me: Oh sweet! I'm going to learn a new language. Me after the video: :O

Comparing types using match types can run you into a problems. Personally I think it is an anti pattern. It's because of disjointness checks which is required to advance to remaining cases. With simple types - everything works well, but problems arise when you want to match against covariant/contravariant generics, or match types. Consider example below: type IsSame[A,B] =A match case B => true case _ => false summon[IsSame[Option[Int],Option[String]] =:= false] It doesn't compile The worst thing is that everything seems to be fine until you start using some more sophisticated types

It was very helpful for me understaing Auto DI using pure scala3. Thank you!

Really well explained! Loved this!

Oh my God! There is so much boiler code to compose two operations. Inserting into a database and sending an email should not require much complexity.

Thank you. But I am a little confused. 15:11 why it’s not blocking. When you call the method you still need to wait the result from another thread right? Forgive my dumbness, I really don’t understand the difference between it and Async non blocking here 4:57.

This is exactly what I needed to get started! Thanks so much.

Finally, an example of using type-level programming in Scala. The simplicity and elegance are impressive. Having worked for years with Java and Spring, I appreciated doing dependency injection explicitly when using Scala. Therefore, I don't think I would use this technique in my own project, but I would be very interested in seeing more examples of how to leverage this technique.

I wrote the same thing in 3 simpler and cleaner in C#

What you can do with the Scala 3 compiler is amazing. I have mixed feelings about this kind of automated dependency injection. I do like that it can result in a lot less code written by the programmer but every time I have worked with something like this I have had to spend a lot of time figuring out all of the magic that is going on under the hood. I do like that this solution is built with plain Scala. No macros or reflection. Interesting stuff

Excuse me, how to benchmark scala apps, could it be used in production?

This was a fantastic view into abstract Scala programming. Brings me back to Haskell. I love how clean you presented your examples.

As interesting as the mechanism is, I'm still not groking how is this or Zlayer more ergonomic that simply instantiating one's dependencies and wiring them via constructor injection. Both approaches require boilerplate in the companion object (and therefore a dependency on the di library). Could you elaborate on that? I am legit terrified I'm being an old man shouting at the clouds here, I'd love to understand this!😂

Odersky is doing a magnificent job and I have no doubt that he will make the language disappear. However, it is always comforting to learn by watching Daniel's videos.

This is a very nice trick, and I love it. It could be useful for simple programs, which is really nice. I would use this in subsets of a bigger project, but I like the ZIO approach much better because it has more advanced and feature-rich options, like repeatability, configurations, etc., which the compile-time constructor can't work with. At least, I think so. Also, this has no error handling, which is something I really love with Zio-type. Safe error handling is really important in big projects.

Th best explanation I've seen on the subject. Great content!

Yeey new Scala video, finally :)

Thank you....could you kindly provide the transcript for the above video, need to read to support your thoughts....thx

Need to try this but its awesome

From simple DI to complex, extra code ZIODI, NO THANK YOU.

really great and simple explainer easy to understand.. big thanks

This is BRILLIANT, thanks! Tuples as heterogeneous lists and match types are real game changers in Scala 3!

Is there a public RFC for this feature?

Ok TLP is needed .. to support it, but not to use it. So i am able to use it without wearing a real black belt 😊

wouldn't it work also with multiple implicits rather than a single using clause with a provider of a tuple

I was actually thinking of trying to implement something like this the other day. Nice to see you doing a video about it and Oderdky coming up with it

A couple of potential issues come to my mind: 1. Config loading based on some condition - e.g. loading different config file based on environment variable or some CLI argument, which will not be possible if the dependencies are resolved entirely on the type level. Usually you have your config as a very first dependency which is fed in the services. 2. Disposing of resources (e.g. acquire and release) is not under our control. 3. Using fresh instance of a layer (e.g. to avoid global uniqueness for a particular layer) To be honest all of the above issues might very well be solvable and this could be a good lightweight DI approach. I really like the clever type level programming and that you managed to mention "Odersky" and "ZIO" in a single video 🙂 Thank you for sharing this interesting idea!

No magic, I like it!

Can we do DI without frameworks?

need a big cup of coffee and go over this, but it looks cool

Please write your impressions of this approach in the comments! If you like it, it's not impossible that it may become a core Scala library or module.

I’d be interested to see conditional dependency injection like Zio layers support - might be possible with an auxiliary data structure that’s indexed like a tuple but the element can be optional/error type

coming from TypeScript, this is awesome!

I come back to this video from fasthtml. :) It was invented in scala too.

Coming from Scala coding, it pains me that people use for loops for iterations instead of mapping 😂

I guess when you said iterations is heavily discouraged in Scala it would have helped to give the reason why, otherwise nice video

Great video. I feel more comfortable now reading query plans. It's still tough!

Masterfully explained !!!

I'm working on refactoring a huge application and switching from Play framework to Zio. I have migrated the services and all I have to do is run the application. I have a problem that I cannot provide more than 512 Zlayers, is there any practical solution for my case? It doesn't make sense that I can't provide ZLayer as much as I want?

quick question, if i want to learn scala native, is it the same as scala? can i do it with this tutorial? or there are some specific resources to do so? Thanks in advance!