[maxbond]

> [B]ecause of the async keyword, library developers would also have to make a different sync/async of each function they want to declare.

This is a program with async in general, no? Go avoids this by just having everything be async, but that seems unsuitable for Rust since you won't have control over when your code executes and what thread it executes on, not a problem for applications but it would seem to rule out things like kernel modules and firmwares, as well as require every type to be Send + Sync (which ultimately means the language must be garbage collected).

In Python for example I've written async and sync versions of a library, and some magic testing that makes sure both implementations return the same results.

> These are not small issues and will only continue to get worse as people are forced to choose one route, leaving others to use a different language.

Honestly this doesn't seem like a problem to me. I think there's room for many languages in this world. Rust is a wonderful language but it isn't a "one true language." People should choose a different language if it suits them better. That's no more an indictment of Rust than it's an indictment of Python when I embed Rust in a web app - that's not a place where Python shines.