4 ms·

> Solving async traits Pretty sure async traits are coming soon (next couple of versions?) which is pretty speedy considering what I understand to be a semi-th

> Solving async traits Pretty sure async traits are coming soon (next couple of versions?) which is pretty speedy considering what I understand to be a semi-thorny problem. > having a proper concurrency runtime story Do you mean the language/stdlib shipping an async runtime? > reducing the reliance on third party crates to ease error handling I for one don't rely on 3rd party crates for error handling often? Anyhow is the most common one I use, but mostly out of habit and laziness, not actual hard requirement....

mcronce 5y ago
I usually use `thiserror` for errors, but all that is is a shortcut macro for `impl Error` and `impl Display`
jupp0r 5y ago
Async error handling has been a nightmare last time I tried a few months ago. Has that improved lately?
- lijogdfljk 5y ago
  Pardon my ignorance, but what do you mean? Handling errors with the async runtime..? If you just mean handling errors from funcs .. it's no different than non-async, no?
  - jupp0r 5y ago
    Yes, if all error types from various libraries are `Send` + `Sync` it's easy, if not, you are running into issues where you need to wrap them in reference counted containers because some of them aren't copyable either. Crates like failure, thiserror and anyhow didn't simplify this (although I really like their general approach to wrapping low level errors in high level errors with a breadcrumb trail to details).
the_duke 5y ago
> Pretty sure async traits are coming soon (next couple of versions?) No. There are ideas for how to do it, but as far as I know they haven't been tested out yet. It also relies on pretty large features that are not proposed for stabilization yet (GAT and existential types). When that is done and the implementation strategy is chosen there will also need to be a RFC cycle, a phase of ironing out bugs and finally stabilization. It'll be ... quite ... a while... I can't see it happening this year.
- tialaramex 5y ago
  GATs are apparently very close to stabilization, I think I've seen Rust 1.62 suggested as plausible. So that's a big step towards the likely design of async traits. But sure, async traits is not likely to be this year. Fortunately although for some reason async traits are on pjmlp's must-have list, they're nowhere close to the critical path for Linux, which again is written today in C.
  - pjmlp 5y ago
    I was replying to "I think Rust is a good position in the sense that the language and community has a track record and culture of going and solving problems instead of sitting on them forever. I agree that many challenges of kernel development are going to end up strengthening and evolving Rust as a language." So I picked some ongoing language examples where this isn't quite true.
    - tialaramex 5y ago
      Isn't it though? I think Rust's processes have done pretty well here. Mara has written somewhere about how effective it is - unlike in a setup like WG21 - to just do stuff in Rust instead of waiting around for some imaginary higher power to grant your wishes, write the code and raise a PR to land your change. For example, suppose you really want Mutex::unlock(). Right now that's behind the feature gate, but it's not controversial, if you feel like this more explicit function call is helpful you could put the work in to stabilize it and get the gate removed in say 1.61. [[ Mutex::unlock(guard) is just equivalent to drop(guard) since of course dropping the guard will unlock the mutex which is why you usually don't do either, your guard will go out of scope and get dropped automatically, so the reason to want Mutex::unlock() is that it reads more naturally ]] In C++ the pointer provenance problem has been sat around for almost twenty years as an unresolved defect in, I believe, C++ 98. In Rust, Aria was like "We should provide a new API to do provenance in a sound way" and she shipped it (admittedly as a nightly feature, not stable) before I'd finished all the prior reading.

mcronce 5y ago

I usually use `thiserror` for errors, but all that is is a shortcut macro for `impl Error` and `impl Display`

jupp0r 5y ago

Async error handling has been a nightmare last time I tried a few months ago. Has that improved lately?

lijogdfljk 5y ago
Pardon my ignorance, but what do you mean? Handling errors with the async runtime..? If you just mean handling errors from funcs .. it's no different than non-async, no?
- jupp0r 5y ago
  Yes, if all error types from various libraries are `Send` + `Sync` it's easy, if not, you are running into issues where you need to wrap them in reference counted containers because some of them aren't copyable either. Crates like failure, thiserror and anyhow didn't simplify this (although I really like their general approach to wrapping low level errors in high level errors with a breadcrumb trail to details).

the_duke 5y ago

> Pretty sure async traits are coming soon (next couple of versions?) No. There are ideas for how to do it, but as far as I know they haven't been tested out yet. It also relies on pretty large features that are not proposed for stabilization yet (GAT and existential types). When that is done and the implementation strategy is chosen there will also need to be a RFC cycle, a phase of ironing out bugs and finally stabilization. It'll be ... quite ... a while... I can't see it happening this year.

tialaramex 5y ago
GATs are apparently very close to stabilization, I think I've seen Rust 1.62 suggested as plausible. So that's a big step towards the likely design of async traits. But sure, async traits is not likely to be this year. Fortunately although for some reason async traits are on pjmlp's must-have list, they're nowhere close to the critical path for Linux, which again is written today in C.
- pjmlp 5y ago
  I was replying to "I think Rust is a good position in the sense that the language and community has a track record and culture of going and solving problems instead of sitting on them forever. I agree that many challenges of kernel development are going to end up strengthening and evolving Rust as a language." So I picked some ongoing language examples where this isn't quite true.
  - tialaramex 5y ago
    Isn't it though? I think Rust's processes have done pretty well here. Mara has written somewhere about how effective it is - unlike in a setup like WG21 - to just do stuff in Rust instead of waiting around for some imaginary higher power to grant your wishes, write the code and raise a PR to land your change. For example, suppose you really want Mutex::unlock(). Right now that's behind the feature gate, but it's not controversial, if you feel like this more explicit function call is helpful you could put the work in to stabilize it and get the gate removed in say 1.61. [[ Mutex::unlock(guard) is just equivalent to drop(guard) since of course dropping the guard will unlock the mutex which is why you usually don't do either, your guard will go out of scope and get dropped automatically, so the reason to want Mutex::unlock() is that it reads more naturally ]] In C++ the pointer provenance problem has been sat around for almost twenty years as an unresolved defect in, I believe, C++ 98. In Rust, Aria was like "We should provide a new API to do provenance in a sound way" and she shipped it (admittedly as a nightly feature, not stable) before I'd finished all the prior reading.