I've done both, but 80% in reactive streams. I like async/await before it has a lot less hard stuff to think about - hot and cold streams take months if not yea

I've done both, but 80% in reactive streams. I like async/await before it has a lot less hard stuff to think about - hot and cold streams take months if not years for devs to grok - and creates code a lot more similar to non-async code. In contrast Reactive Streams requires you to change your complete program. I like to compare it to Typescript/Kotlin-style null-safety v.s. the Java Optional or Scala Option. If you want make code null safe with option you have to rewrite basically your complete code from "procedural" to chains of (flat)maps. In contrast in Typescript you just change T to T? in a few places and add an if where you want to handle the optionality. async/await versus reactive streams has this same problem, reactive streams is highly impactful, much more than async/await. In practice I've seen this have the effect of turning applications turn into a small reactive stream outer shell with the app itself being mostly synchronouse/Future, while async/await is used a lot more liberally because the impact is smaller. > It seems like a worse abstraction because it mixes asynchronous code with synchronous code It doesn't, at least in Kotlin only an async function can call an async function. This isn't different from using `map` in a stream.