[haberman]

I see two solid points here:

1. It's not reasonable to expect the application layer to carefully partition its work into "I/O heavy" and "CPU heavy" parts.

2. It's not reasonable to queue up an arbitrary amount of work without back-pressure.

I haven't used Tokio much, but if it falls prey to these pitfalls, it would make me pause before adopting it.

I think there are probably ways of using Rust async that don't fall prey to these. Maybe not so much with network servers (I haven't written that many of those), but models where you are evaluating a graph and have more control over how new work is added to the system.

[lunar_mycroft]

I think 2 is a reasonable concern (and one which has solutions in rust async/await tokio, as FridgeSeal points out). I'm not sure about 1 though. I think having a rough idea what part of your programs are computationally expensive shouldn't be to much to ask of programmers.

[FridgeSeal]

> but if it falls prey to these pitfalls, it would make me pause before adopting it.

This issue isn't really a Tokio concern, it's pretty straightforward to write Rust code that has back pressure mechanisms. The "it's not reasonable" in my mind implies that if someone goes and _does that_ then there's not much a library can do to restrain the developer.

[swiftcoder]

> It's not reasonable to expect the application layer to carefully partition its work into "I/O heavy" and "CPU heavy" parts.

If your application has both of these and doesn't partition them, you already have a fundamental flaw in your application architecture. Every serious piece of software does this, from web GUIs, to servers, all the way to video games.

> It's not reasonable to queue up an arbitrary amount of work without back-pressure

Absolutely, which is why we use pull-futures instead of push-futures, across the entire rust ecosystem. Creating unbounded queues in Tokio requires a fair bit of error on the part of the programmer

[pmbanugo]

It's not a problem specific to Rust. It's more around async/await as a concurrency primitive. Same can be said about Node.js or many other languages