4 ms·

That is the case, but it's super awkward to use. Basically, you cannot await a tokio future on an async-std runtime, or an async-std future on a tokio runtime.

That is the case, but it's super awkward to use. Basically, you cannot await a tokio future on an async-std runtime, or an async-std future on a tokio runtime. You can, however, have both runtimes running at the same time, and use some form of message-passing to bridge them. It's definitely easier to only deal with one runtime. Ideally, we should have some kind of abstraction to allow crates to support both runtimes (e.g. a trait that'd allow creating an async TcpSocket of the right "kind" for your runtime), but AFAIK this is not currently done.

steveklabnik 6y ago
> AFAIK this is not currently done. That's correct; we're still working on these abstractions. It's the end goal that most folks have in mind, though.
- jeffdavis 6y ago
  Can you explain and/or link to the issues? I thought Futures were the abstraction that lets you choose a runtime?
  - Rusky 6y ago
    Futures are part of the answer, and more specifically the way that the Wakers passed to Future::poll use dynamic dispatch to re-schedule the task. Other major abstractions that are missing so far include async versions of the Read and Write traits, a Stream trait for the async equivalent of the Iterator trait, and perhaps a way to spawn new tasks. This series of interviews covers these in more depth: http://smallcultfollowing.com/babysteps/blog/2020/04/30/async-interviews-my-take-thus-far/ http://smallcultfollowing.com/babysteps/blog/2020/04/30/asyn...
empath75 6y ago
I was looking at smol and it seems to have a good pattern for working with all the other run times.
deleted 6y ago
[deleted]
Matthias247 6y ago
> That is the case, but it's super awkward to use. That's really the case for any language where an eventloop is not part of a builtin runtime (like it e.g. is with Javascript or Dart). E.g. in C++ we also have boost asio, libuv, libevent, wagle, seastar,GUI framework eventloops in GTK, QT, etc. The thing is once you are in async land, nothing is interoperable anymore in most environments. Whether that's ideal or not is a separate discussion. What I experience however somehow is that Rust users raise a lot more concerns about interoperability than I've seen so far in other ecosystems. I might stem from the fact that those users often never used another native async environment.
- wwright 6y ago
  IMO it’s more that the Rust community has fostered a culture of doing things carefully and doing them well whenever possible (I mean, it’s the language that will argue with you for hours over reference lifetimes, after all).
  - Matthias247 6y ago
    There are certainly high expectations in the Rust community about doing things perfectly. But I don't think those "async ecosystem" discussions are a good example of productive discussions. I think e.g. in C++ there had been far more expert talk on standarization, within expert groups - like for the standarization of executors or the networking TS. And yet after 5 years or so nothing had been standardized yet. In Rust the amount of people that actually work on the low level details and try to make things better is likely < 5. But there are a lot of expectations from everyone else about having perfect interoperability.
xrd 6y ago
Does anyone here have any experience using Kotlin and can compare concurrency (with coroutines) to either Go or Rust? When I was doing more Java I really liked the approach Kotlin took with concurrency, but reading the comments here I'm sure I didn't understand the issues at the depth that is needed.

steveklabnik 6y ago

> AFAIK this is not currently done. That's correct; we're still working on these abstractions. It's the end goal that most folks have in mind, though.

jeffdavis 6y ago
Can you explain and/or link to the issues? I thought Futures were the abstraction that lets you choose a runtime?
- Rusky 6y ago
  Futures are part of the answer, and more specifically the way that the Wakers passed to Future::poll use dynamic dispatch to re-schedule the task. Other major abstractions that are missing so far include async versions of the Read and Write traits, a Stream trait for the async equivalent of the Iterator trait, and perhaps a way to spawn new tasks. This series of interviews covers these in more depth: http://smallcultfollowing.com/babysteps/blog/2020/04/30/async-interviews-my-take-thus-far/ http://smallcultfollowing.com/babysteps/blog/2020/04/30/asyn...

empath75 6y ago

I was looking at smol and it seems to have a good pattern for working with all the other run times.

deleted 6y ago

[deleted]

Matthias247 6y ago

> That is the case, but it's super awkward to use. That's really the case for any language where an eventloop is not part of a builtin runtime (like it e.g. is with Javascript or Dart). E.g. in C++ we also have boost asio, libuv, libevent, wagle, seastar,GUI framework eventloops in GTK, QT, etc. The thing is once you are in async land, nothing is interoperable anymore in most environments. Whether that's ideal or not is a separate discussion. What I experience however somehow is that Rust users raise a lot more concerns about interoperability than I've seen so far in other ecosystems. I might stem from the fact that those users often never used another native async environment.

wwright 6y ago
IMO it’s more that the Rust community has fostered a culture of doing things carefully and doing them well whenever possible (I mean, it’s the language that will argue with you for hours over reference lifetimes, after all).
- Matthias247 6y ago
  There are certainly high expectations in the Rust community about doing things perfectly. But I don't think those "async ecosystem" discussions are a good example of productive discussions. I think e.g. in C++ there had been far more expert talk on standarization, within expert groups - like for the standarization of executors or the networking TS. And yet after 5 years or so nothing had been standardized yet. In Rust the amount of people that actually work on the low level details and try to make things better is likely < 5. But there are a lot of expectations from everyone else about having perfect interoperability.

xrd 6y ago

Does anyone here have any experience using Kotlin and can compare concurrency (with coroutines) to either Go or Rust? When I was doing more Java I really liked the approach Kotlin took with concurrency, but reading the comments here I'm sure I didn't understand the issues at the depth that is needed.