I was recently was on a project-not in Scala!-which used async/await for asynchronous computations. Async/await is "syntactic feature of many programming languages that allows an asynchronous, non-blocking function to be structured in a way similar to an ordinary synchronous function." (Wikipedia) Using it was very confusing to me as I had first learned async programming with Futures. I have to use some magic keywords when dealing with async code? Why would anyone want to do this, instead of using a monad like Future? (Monad just means you can flatMap() it or use it in a for-comprehension.)
It took me a couple of weeks to become comfortable, but I started to understand the rationale of async/await and would like to share it with you, so you don't have to be as confused as I was-or at least for as long. You'll learn:
Many modern languages use async/await, such as Rust and Javascript. Even though Scala doesn't natively support async/await yet-it's being discussed, and there are compiler plugins and libraries that offer support for it-learning the technique will improve your understanding of asynchronous programming and allow you to better understand other codebases… as you are porting that code to Scala!.
Concurrent coordination is a notoriously difficult problem: how do we make the behavior of a computation depend on another, concurrently running one? Or more than one? We'll show one technique: the concurrent state machine, and build many examples using the powerful Cats Effect library.
For example, how can we share state between effects when that state might be concurrently updated? Or how can we ensure one effect only proceeds once work is complete in another? We'll discuss the first issue by using the Ref data type for sharing mutable state. We'll then show how the Deferred data type can provide concurrent effect serialization without blocking any actual threads. Finally we'll model even more complex behavior by composing these two concurrency primitives together to form a concurrent state machine.
Some concurrent coordination behaviors we can construct using this method are:
There's a joke that a framework is a product with the business logic removed, but all the assumptions left in. In this talk we'll explore an alternative: solving the most common enterprise issues with the composable ecosystem of Typelevel libraries, avoiding not-invented-here (NIH) and lock-in.
We've been involved in many enterprise projects, and have seen many recurring patterns implemented in an ad-hoc, fragile way. At the same time, and more often than not, any custom libraries rapidly develop "bit-rot", creating a maintenance burden. Instead we can be brave! We can avoid the sunk-cost fallacy by refactoring and retooling using powerful and composable abstractions. We can also trust we are reducing our risk because of the high quality of these open source projects.
We'll dive deep into how to use the Typelevel stack to handle common tasks like data validation, integration with data sources and sinks, the modeling of actions associated with state machines, and more. We'll be using libraries like cats, cats-effect, refined, and more, to fix and extend existing systems to be more powerful, safer, and ultimately more maintainable.
Cats Effect is a library that makes it easy to write code that effectively uses multiple cores and doesn't leak resources. This makes building complex applications, such as highly concurrent services, much more productive.
This talk will introduce the meaning and role of side-effects and effects, how to encapsulate side-effects in a safer form, and show off the features of the Cats Effect library that provide parallelism, concurrency, resource-safety, and more!
Source, license and issues can be found at https://github.com/arosien/talks .