5 ms·

> One of the biggest ones to point out is that async runtimes are still a bit unclear. There are currently two different options to choose from, each of them wi

by shock 6y ago

> One of the biggest ones to point out is that async runtimes are still a bit unclear. There are currently two different options to choose from, each of them with their own tradeoffs and problems. Also, many of the implementation details are tied to specific runtimes, meaning that if you have a dependency that uses one runtime over another, you’ll often be locked into that runtime choice. My understanding of how async/await works in Rust is that you can have multiple async runtimes in one Rust program. Is that not the case?

roblabla 6y ago
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.
gas9S9zw3P9c 6y ago
In theory you can, but in practice it would make your code very messy. If your dependency is using runtime A and you are using runtime B - how would they interact? Runtimes like tokio also provide convenience macros for you main mehtod, kind of locking you into them (I think), at least for that codepath. If your application has two parts or binaries that are completely separate you could potentially use two different runtimes, but otherwise I don't think it would make sense. And even then, it would just be a mess. Right now, your runtime is essentially picked for you by your dependencies.
Rusky 6y ago
It's possible, the downsides are a bit silly when you look at how the Future trait was designed to allow tasks to be runtime-agnostic. There is ongoing work to standardize more runtime interfaces so that more libraries can be runtime-agnostic.
mappu 6y ago
Going off on a tangent, but this exact problem would be a worst-case scenario for Go getting user-defined generic types instead of only the current blessed ones. t. C++ developer with a mixed std::string/QString/BSTR codebase.
- comex 6y ago
  But strings are not generic types...
- zxcmx 6y ago
  So much this. Have seen apps where there were 4 diff string types brought by external dependencies and then like 3 or 4 more to deal with from diff Windows APIs.
- monocasa 6y ago
  Well, that's the current state of Go if the half dozen blessed versions don't fit your use case. Everyone just writes their own slightly incompatible versions.
- adev_ 6y ago
  > t. C++ developer with a mixed std::string/QString/BSTR codebase. This has absolutely nothing to do with generics. None of std::string or QString are generics. They are just an example of historical alternative implementations for 'reasons' ( portability/speed) that create a lesson the long term
  - slavik81 6y ago
    It's also unavoidable. It's not like you can pass UTF-8 Go strings to UTF-16 COM interfaces. Somebody wrote code to convert a Go string to a BSTR and vice versa. You can do the exact same thing for std::string if you want.

by shock 6y ago

roblabla 6y ago

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.

gas9S9zw3P9c 6y ago

In theory you can, but in practice it would make your code very messy. If your dependency is using runtime A and you are using runtime B - how would they interact? Runtimes like tokio also provide convenience macros for you main mehtod, kind of locking you into them (I think), at least for that codepath. If your application has two parts or binaries that are completely separate you could potentially use two different runtimes, but otherwise I don't think it would make sense. And even then, it would just be a mess. Right now, your runtime is essentially picked for you by your dependencies.

Rusky 6y ago

It's possible, the downsides are a bit silly when you look at how the Future trait was designed to allow tasks to be runtime-agnostic. There is ongoing work to standardize more runtime interfaces so that more libraries can be runtime-agnostic.

mappu 6y ago

Going off on a tangent, but this exact problem would be a worst-case scenario for Go getting user-defined generic types instead of only the current blessed ones. t. C++ developer with a mixed std::string/QString/BSTR codebase.

comex 6y ago
But strings are not generic types...
zxcmx 6y ago
So much this. Have seen apps where there were 4 diff string types brought by external dependencies and then like 3 or 4 more to deal with from diff Windows APIs.
monocasa 6y ago
Well, that's the current state of Go if the half dozen blessed versions don't fit your use case. Everyone just writes their own slightly incompatible versions.
adev_ 6y ago
> t. C++ developer with a mixed std::string/QString/BSTR codebase. This has absolutely nothing to do with generics. None of std::string or QString are generics. They are just an example of historical alternative implementations for 'reasons' ( portability/speed) that create a lesson the long term
- slavik81 6y ago
  It's also unavoidable. It's not like you can pass UTF-8 Go strings to UTF-16 COM interfaces. Somebody wrote code to convert a Go string to a BSTR and vice versa. You can do the exact same thing for std::string if you want.