It's interesting how over the past several decades we've learned a lot about which features should be part of a language's standard distribution and which can be farmed off to third-party libraries. String types, standard data structures, package managers, concurrency/async features, type systems, object models, date formats, command-line parsing, log libraries, parsers for the language itself, documentation generators - all of these can be implemented as add-on libraries and have been in at least one language, but we've found that this results in chaos in the language ecosystem. Similarly, protocol parsers, web frameworks, ORMs, command-line utilities (readline/curses, not argparsing), GUI frameworks - all of these have been wrapped into the stdlib of some library or other, but we've found that they aren't essential, and are often better off as a third-party package.

The one feature that IMHO should get baked into a language but nobody's done right yet is API versioning. Wish more people paid attention to the evolution of a program over time rather than a snapshot of where it is now.

Well, you're talking about things where time and experience has more or less found that having everything in a language working the same exact way makes for huge productivity gains and in most cases it's easy to escape hatch out if you really need special behavior, but most of the time you don't versus things where almost no one wants to use the same shit.

> ..., while people not writing asynchronous code can pretty much ignore it if they want to.

I don't think this is strictly true. If there is code which is available only in async form, then it's either unusable or awkward to use at best for someone using the non-async form. And vice-versa.

This is something I've found to be a problem in C#. Specifically, trying to use Microsoft async only API from sync code. And that async API really requires the whole stack to be async, so using the APIs from sync code requires hacks found at Stackoverflow.

It's a split in the code base, and extra work and complication for developers. I'm not saying that it's not worth it, or it shouldn't go in.

> If there is code which is available only in async form, then it's either unusable or awkward to use at best for someone using the non-async form. And vice-versa. [...] It's a split in the code base, and extra work and complication for developers.

This is already the case today. As I pointed out, there is currently a split into about 4–5 (at least) mutually incompatible versions of I/O and network protocol related code. The new features should cut that down to 2–3, which are easier to understand and reason about, to boot.

When I say people can ignore the changes, what I really mean is: to the extent they can ignore the complexities of syntax and semantics around asynchronous code today, they can continue to do so in the future.

Alternately, having language support and a solid built-in library might encourage some people to write their code using asynchronous rather than blocking I/O, without too terribly difficult a learning curve or too much mental overhead from the new abstractions.

You're right about asyncio, but the new async PEP undeniably adds a lot of complication to a story which was already working.