There is no right answer on this front, and it's all about different use cases.
It comes down to I/O-bound vs CPU bound workloads, and to how negatively things like cache evictions and lock contention might affect you. If your thing is an HTTP server talking to an external database with some mild business logic inbetween, and hosted on a shared virtual server, then, yeah, work-stealing and re-using threads at least intuitively makes sense (tho you should always benchmark.)
If you're building a database or similar type of system where high concurrency under load with lots of context switches is going to lead to cache evictions and contention all over the place -- you're going to have a bad time. Thread per core makes immense sense. An async framework itself may not make any sense at all.
But there is no right, dogmatic answer on what "is better." Profile your application.
I've said it before, but I feel like the focus of Rust as a whole is being distorted by a massive influx of web-service type development. I remain unconvinced that Rust is the right language for that kind of work, but it seems to do ok for them, so whatever. But the kind of emphasis it puts on popular discussion of the language, and the kind of crates that get pushed to the forefront right now on the whole reflect this bias. (Which is also the bias of most people employed as SWEs on this forum, etc.)
I haven’t really seen any issues with async affecting other parts of Rust. People are successfully building systems applications, including game engines, cryptography libraries, kernels, command line tools, compilers, etc, all without having to touch async.
I maintain large cryptography libraries, and have been completely unaffected by the async business.
I gripe about it all the time, but it hasn't really been an issue for me, and TBH the biggest codebase that I've written outside of work (where we don't really use async) ... uses tokio.
I think it's more a question of emphasis. If you go looking for crates for network I/O related things (esp HTTP) on the whole you'll find mostly async driven ones. And among them, you'll often find they're hardcoded for tokio, too.
Funny, I was thinking a web app is ideal for thread per core. The application itself generally has very little state outside of a request (other than for the socket listener and database connections, which can be segmented per thread), and what state it has is probably mostly static across requests (so caches don't invalidate often). It should be easy to deal with ownership of shared state because there isn't any.
>.. focus of Rust as a whole is being distorted by a massive influx of web-service type development.
True, I think it happened because Rust community quite aggressively sought out those developers to gain market and mindshare. I am not saying it is bad or good but now Rust has to live with unending stream of web related libraries and frameworks of varied quality.
And async will remain constant topic of discussion because most of critical base libraries/crates etc have taken async first approach. Now it is to a level that normal devs can not write plain sync code for business problems unless they make not using async one of main point of their projects.
> True, I think it happened because Rust community quite aggressively sought out those developers to gain market and mindshare.
Guilty as charged, honestly. But we were really target high performance web services where Rust really makes sense. And Rust has had a lot of success gaining market share in that area, but most people who work on things like that are writing closed source software and don't comment so much on the internet, so what you see online is mostly people blogging about their side project that doesn't need to serve a million concurrent connections.
I feel lucky(-ish) that the only web Rust project I've ever really worked on is one that absolutely takes advantage of Rust's performance, Cloudflare's Pingora. But yeah, CRUD app #64326 probably should just use Rails/Django/Phoenix/Go/etc. instead of Rust.
This makes me think of another reason of Rust in web space. It is that Rust rather explicitly tried to create an image of real hardcore language used for serious systems stuff. And it is of course true in technical sense. In larger context however message became more of like if I use Rust my stuff will become serious.
So now if someone is told their web app is cute little thing more suited for Rails/PHP/Go etc. they will feel patronized and try to use Rust despite being unsuitable because their app is going to be serious one.
I had someone reach out to try to hire me last year to build a website. A neat and useful one, but a website. And they had decided they wanted to use Rust, so they got in touch with me. This person was primarily non-technical, but an entrepreneur. I couldn't understand the decision making that led them there, other than: people had told him that Rust was the new good thing. So that's what he wanted.
It comes down to I/O-bound vs CPU bound workloads, and to how negatively things like cache evictions and lock contention might affect you. If your thing is an HTTP server talking to an external database with some mild business logic inbetween, and hosted on a shared virtual server, then, yeah, work-stealing and re-using threads at least intuitively makes sense (tho you should always benchmark.)
If you're building a database or similar type of system where high concurrency under load with lots of context switches is going to lead to cache evictions and contention all over the place -- you're going to have a bad time. Thread per core makes immense sense. An async framework itself may not make any sense at all.
But there is no right, dogmatic answer on what "is better." Profile your application.
I've said it before, but I feel like the focus of Rust as a whole is being distorted by a massive influx of web-service type development. I remain unconvinced that Rust is the right language for that kind of work, but it seems to do ok for them, so whatever. But the kind of emphasis it puts on popular discussion of the language, and the kind of crates that get pushed to the forefront right now on the whole reflect this bias. (Which is also the bias of most people employed as SWEs on this forum, etc.)