[FridgeSeal]

> 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....

[the_duke]

> 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]

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]

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]

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.

[FridgeSeal]

Ah, my bad, thanks for the correction! I think I might have got that timeline confused with some other feature haha.

[mcronce]

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

[jupp0r]

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

[lijogdfljk]

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]

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).