[j1elo]

Talking about this specifically, yes it's difficult to think of a reason to change ranges in the future.

But bringing my post to a more general stance, I'm of the opinion that Rust is fixated a bit too much on the goal of having a minimal core and leaving the ecosystem to find its own ways forward. Maybe it wouldn't hurt that much if the language, with its current age, started opening up to providing more of the stuff that's currently deemed "inappropriate" for the stdlib. Didn't we have enough time to let the bazaar do its thing and come up with some locally optimal API designs yet? While having a consistent way to version APIs (such as the mentioned Go's /v2) solves the issue of "being stuck forever".

I guess all this to say that extremes are never healthy. The Rust Way is a good one for letting the community discover and experiment, but not even compromising on an async engine is (as always, IMHO) taking it a bit too far.

[steveklabnik]

Async engines are one of the worst things you could have chosen as an example. They are wide and varied, with a ton of different tradeoffs for different scenarios. Ones for high performance networking are also complex, requiring tremendous engineering effort, and are massive. Putting something in the stdlib doesn’t magically make something better maintained.

Interfaces also do not magically become good or useful. There has been suggestions around some async traits, but no suitable one has actually been found yet. Yes, it has been a very long time, but that’s just how it goes sometimes.

[yencabulator]

> but not even compromising on an async engine

FWIW, Tokio's API is not the right one for io_uring, buffer pools for reads changes everything. There'll be yet another huge ecosystem churn. I'm personally hoping for it to happen sooner rather than later.