Keynote: Daniel Spiewak - The Case For Effect Systems
Вставка
- Опубліковано 2 лип 2024
- Scaling and stabilizing cloud services in the face of torrential volumes of traffic is one of the major problem spaces that defines our language ecosystem. Problems such as reliability, predictability, throughput, efficiency, self-healing, and such are the primary factors which largely dictate both architectural and implementation decisions.
In this talk, we will peel apart how these factors manifest on the JVM, ultimately motivating not only the asynchronous I/O paradigm in general but effect systems in particular, with a special emphasis on performance and efficiency in the real world.
2022.scala.love
/ scala_love - Наука та технологія
This is the best explanation of the effects system ever. I was trying to explain it to my colleagues and this is the talk they need ! Thx you you ROCK!
Such a knowledgeable guy
It's nice to go back to this talk! Thanks a lot for the presentation.
Really great presentation. I just loved it.
Thank you! I learned so much from this talk.
Thank you for this great keynote, and you've described and summarized perfectly the pathway (by chance and experimentation) I've followed this past two years :)
I think speaker meant cache misses instead of page faults around 12:00.
If every thread's working set is huge or physical RAM is small, then only switching threads will cause more page faults. Both of these are not a concern in typical micro services.
Another banger, thanks man
this was a good talk
I would love to see this presentation revamped in light of Java 21 Virtual Threads, Structured Concurrency, and Scoped Values...
This talk is already talking about this.
And it talks about it. The runtime system of effects system has more features that loom is offering. I also see loom as not bringing values to Effect System usage. The loom can be exploited in the runtime implementation of the effect system.
@@MrDejvidkit too bad cala is DOA
The concept of closing a resource reminds me of a destructor.
At 9:59, Daniel says there are 2 physical threads and 5 threads in application space. I thought in Java/Scala, Thread refers to the actual operating system level thread? What is the difference here?
I believe this exemplifies a CPU with 2 cores that is able to only handle 2 system threads at any given time. If there are more than 2 system threads created (5 in this scenario), CPU will be switching between them.
And switching between system level threads on 2 physical CPUs will cause cache misses if workloads of async operations (future) are processed with different threads on different physical CPU. You don't have control over this on Future based codebase. You can manipulate the execution context but that is about it.