(Replying to PARENT post)

People crap on async Rust because it's not the most graceful to use, but I think it's kinda genius how they've managed to make it zero-overhead. To the point that even the stack size of green "threads" is known ahead of time.

The only issue I have is that it's tough not to use it. The big HTTP libraries let you opt out, but smaller libraries don't have the resources to do everything twice. I don't know what the solution is, but it would be nice to always be able to chose. It's pretty silly to use async networking in a cli app, for example, but sometimes you have to.

๐Ÿ‘คpkulak๐Ÿ•‘3y๐Ÿ”ผ0๐Ÿ—จ๏ธ0

(Replying to PARENT post)

> To the point that even the stack size of green "threads" is known ahead of time.

This is only possible by not having stacks for those "green threads" (they're stackless coroutines, not stackful fibers/proper green threads).

It puts a severe limitation on the usefulness and forces any kind of recursive coroutine to heap allocate on returns.

๐Ÿ‘คduped๐Ÿ•‘3y๐Ÿ”ผ0๐Ÿ—จ๏ธ0

(Replying to PARENT post)

> The big HTTP libraries let you opt out (of async)

At least for reqwest it just wraps the async code in something like `block_on`: https://github.com/seanmonstar/reqwest/blob/5397d2cf8eaecc9f...

And as the sibling comment says, you can do that in your own code. It does still add Tokio to your binary size, and add some compile time, and probably start a bunch of worker threads you don't need, but it does work.

๐Ÿ‘คReactiveJelly๐Ÿ•‘3y๐Ÿ”ผ0๐Ÿ—จ๏ธ0

(Replying to PARENT post)

You can always just do let no_async = block_on(something_async);
๐Ÿ‘คCryZe๐Ÿ•‘3y๐Ÿ”ผ0๐Ÿ—จ๏ธ0