3 ms·

I think the issue in question is more mundane - if someone publishes an async database client library, its currently hardwired to a specific async runtime, so y

by jalk 4y ago

I think the issue in question is more mundane - if someone publishes an async database client library, its currently hardwired to a specific async runtime, so you cannot not easily use it if you are not already using that runtime. The common async abstraction being worked on, sets out to solve that.

lvass 4y ago
>hardwired to a specific async runtime With version constraints, right? IIRC you can end up with multiple versions of multiple async runtimes in a project. I think it'd be better to only have a single one hardwired to the compiler like python's asyncio, even if it likewise sucked.
- WaxProlix 4y ago
  I haven't used much Python recently, but iirc you can just import your own runtimes, too. Twisted, gevent, that sort of thing. Having some sort of sane defaults bundled gives you a really nice baseline for interop, but doesn't preclude you from picking things that fit your use case better. Definitely feels like one place where Rust kinda dropped the ball, at least from a user perspective in $CURRENTYEAR.
  - lvass 4y ago
    True, what I meant is that asyncio is part of the interpreter so you are very unlikely to have trouble with incompatible versions of asyncio. Twisted and gevent don't use async/await, but there's Trio which does and is saner than asyncio, but thankfully library authors aren't forcing it's usage. It's also possible to write libraries that use async but you bring your own runtime (trio or asyncio) with AnyIO.
- craftkiller 4y ago
  Rust libraries can have implementations for each async runtime and then you can pick between them using features. For example, when using sqlx with tokio I would have this in my Cargo.toml: [dependencies] sqlx = { version = "0.5", features = [ "runtime-tokio-rustls", "sqlite", "migrate" ] } But I also could use async-std with: [dependencies] sqlx = { version = "0.5", features = [ "runtime-async-std-rustls", "sqlite", "migrate" ] } So you should be able to get all your deps on a single runtime.
- nicoburns 4y ago
  In practice both major runtimes have long-term stability guarantees (e.g. tokio has committed to maintained 1.0 for at least 5 years), so if you use libraries compatible with Tokio 1.0 then you're unlikely to have issues with this for some time.
- howinteresting 4y ago
  Tokio 1 is the only async runtime used in production at scale, there's very little reason to use anything else. So you can seek out libraries that use tokio 1 and ignore anything else.
- aliceryhl 4y ago
  It's not possible to have multiple 1.x.y versions of the same crate in your project, so you would need a really old library that depends on Tokio 0.2.x for that to happen. This isn't something that normally comes up in practice.
saurik 4y ago
I mean, I would hope "easily" would happen because I can always just use two async runtimes... if they were "interoperable". I can quite easily have a number of separate I/O abstractions and schedulers all happening at the same time in C++, for example, and I never think much about it: I just co_await and it, well, waits.

by jalk 4y ago

lvass 4y ago

>hardwired to a specific async runtime With version constraints, right? IIRC you can end up with multiple versions of multiple async runtimes in a project. I think it'd be better to only have a single one hardwired to the compiler like python's asyncio, even if it likewise sucked.

WaxProlix 4y ago
I haven't used much Python recently, but iirc you can just import your own runtimes, too. Twisted, gevent, that sort of thing. Having some sort of sane defaults bundled gives you a really nice baseline for interop, but doesn't preclude you from picking things that fit your use case better. Definitely feels like one place where Rust kinda dropped the ball, at least from a user perspective in $CURRENTYEAR.
- lvass 4y ago
  True, what I meant is that asyncio is part of the interpreter so you are very unlikely to have trouble with incompatible versions of asyncio. Twisted and gevent don't use async/await, but there's Trio which does and is saner than asyncio, but thankfully library authors aren't forcing it's usage. It's also possible to write libraries that use async but you bring your own runtime (trio or asyncio) with AnyIO.
craftkiller 4y ago
Rust libraries can have implementations for each async runtime and then you can pick between them using features. For example, when using sqlx with tokio I would have this in my Cargo.toml: [dependencies] sqlx = { version = "0.5", features = [ "runtime-tokio-rustls", "sqlite", "migrate" ] } But I also could use async-std with: [dependencies] sqlx = { version = "0.5", features = [ "runtime-async-std-rustls", "sqlite", "migrate" ] } So you should be able to get all your deps on a single runtime.
nicoburns 4y ago
In practice both major runtimes have long-term stability guarantees (e.g. tokio has committed to maintained 1.0 for at least 5 years), so if you use libraries compatible with Tokio 1.0 then you're unlikely to have issues with this for some time.
howinteresting 4y ago
Tokio 1 is the only async runtime used in production at scale, there's very little reason to use anything else. So you can seek out libraries that use tokio 1 and ignore anything else.
aliceryhl 4y ago
It's not possible to have multiple 1.x.y versions of the same crate in your project, so you would need a really old library that depends on Tokio 0.2.x for that to happen. This isn't something that normally comes up in practice.

saurik 4y ago

I mean, I would hope "easily" would happen because I can always just use two async runtimes... if they were "interoperable". I can quite easily have a number of separate I/O abstractions and schedulers all happening at the same time in C++, for example, and I never think much about it: I just co_await and it, well, waits.