Why you might want async in your project

Post by cies » Wed, Sep 13, 2023, 11:31 AM UTC

za3faran wrote: post #163

cies wrote: post #127

Earlier quoted context omitted.

I think sealed interfaces it not quite the same as "tagged unions"-style enum's with payloads. Also, it does not matter much anymore, the whole std-lib is full of exceptions-to-implement-multiple-return-values.

sealed interface Shape {} record Square(int x) implements Shape {} record Rectangle(int l, int w) implements Shape {} record Circle(int r) implements Shape {} double getArea(Shape s) { // Exhaustively checks for all alternatives. return switch (s) { case Square(var x) -> x * x; case Rectangle(var l, var w) -> l * w; case Circle(var r) -> Math.PI * r * r; } } This is a good article: https://mccue.dev/pages/11-1-21-smu…

Loved the article. Thanks for sharing. Maybe I (coming from Haskell and Elm) should not be bothered too much with the verbosity of Java/Kotlin "sum types" :)

Post by insanitybit » Wed, Sep 13, 2023, 3:54 PM UTC

vc8f6vVV wrote: post #180

insanitybit wrote: post #178

Earlier quoted context omitted.

> As I understand it's not possible in Rust async model, You can block, you're just going to block all other futures that are executed on that same underlying thread. But all sorts of things block, for loops block. This is the same as Java, I believe. Akka also has special actors called IO Workers that are designed for blocking work - Rust has the same thing with `spawn_blocking`, which will place the work onto a ded…

If you block your timer goes out the window, right? Because the poll will never get there until the blocking call is done. So yeah, you can block, but it will disrupt the whole chain, including tasks above yours up to await. Similar to Erlang VM where the language itself yields (e.g. there are no loops and every recursive call is effectively a yield), but if you add a C module and are careless enough to block, the wh…

> If you block your timer goes out the window, right?

This is the case in every language.

> So no, if you want to use async you shouldn't block.

Everything blocks. The dosage makes the poison.

> For loops? Nope, not if they take long time for the same reason

You would want to add a yield in your loop, yes. Async loops `while let Some(msg) = stream.next().await` will work well for this.

> And the upward poisoning means that I can't block in my function if my web server is based on async, which affects everybody who is using it.

To be clear, you can definitely block as much as you want in those frameworks, you just need to understand that you'll block the entire thread that's running your various futures. That's not that big of a deal, you'd have the exact same issue with a synchronous framework. Blocking in an OS thread still blocks all work on that thread, of course.

Re: Why you might want async in your project

Re: Why you might want async in your project