2 ms·
I'd like to have some clarification on the following claims: - Rust async is a mess - Python async is a mess What does "mess" means here? I have been wri
by linkdd 4y ago
I'd like to have some clarification on the following claims:
- Rust async is a mess
- Python async is a mess
What does "mess" means here?
I have been writing Rust code for a few months, and Python code for more than a decade. I have to admit that I do not know the internals of the Python's async model, but as a "user", I think that trio (and asyncio with 3.10 / 3.11 is getting better) is really great.
The ability to call `trio.run` / `asyncio.run` anywhere to start an async loop does not "contaminate" the async/await keywords up to the entrypoint. Which is great.
In Python, calling an async function returns a coroutine object (that can be awaited). In Javascript it returns a Promise. In Rust it returns a Future.
From the "user" point of view, it's all the same. And I don't know many developers who are interested in how it works under the hood, because (like in math/physics/science in general) it's very useful to sit on the shoulders of others.
If I understand correctly, Rust gives you the tools, and the "shoulders" belong to the library developers (like tokio). Which is fine to me.
So, I really do not understand what "mess" means, what it refers to, and what I (as a "user") can do about it. Also, if the internals change, how will this impact my code?
- bvrmn 4y agotrio and stdlib has different primitives for sleeping/locking/garhering/etc. And you can't change loop implementation by simple ioloop_of_this_year.run(async_main) in the main().
- linkdd 4y agoThis is nitpicking, I never said that. There is still no explanation for what "mess" means, but I don't think it means having multiple competitors providing an implementation. The fact that there are multiple async Python libraries means that the internals are generic enough to allow that. From what I understand of Rust, there could be another "tokio" as well. And they would not necessarily be compatible either. This is like saying "You can't use a Django model with SQLAlchemy".