Solving async traits, having a proper concurrency runtime story, reducing the reliance on third party crates to ease error handling does seem to take out forever.
While I agree that these are problems (and, they are being addressed), none of these problems are ones that have to do with Rust in Kernel. The developers actually keep a wishlist of potential or unstable Rust/libstd/libcore/tooling features they'd consider helpful: https://github.com/Rust-for-Linux/linux/labels/prio%3A%20met...
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....
> 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.
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.
"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.
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.
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).
I like your input, as critical as it is. Rust is developed by a community/foundation in contrast to C# (Java+). Anders Heilsberg, a brilliant language designer/BDFE can ponder and decide, after careful consideration, top down. Consensus takes time.
> Solving async traits, having a proper concurrency runtime story
Something something let the Java guy cast the first stone.
> reducing the reliance on third party crates to ease error handling does seem to take out forever.
I've written a ton of Rust and I've never used any of these third party error convenience libraries. As far as I'm concerned there is no issue in need of solving around error handling in Rust.
The "please don't offend this language I have intertwined with my own identity with" attitude in modern times is so tragic.
I have always been, and will be, plenty of things, and if it makes you feel good to call me Java guy, when someone criticizes your beloved Rust, please do.
Meh. You often reply prolifically in threads that mention Java, defend/praise it profusely, and also seem to be very knowledgeable about the language as well as the JVM. So it's not entirely an insult when I call you a "Java guy".
But you're over-reading into my defense of Rust. My point is that the specific things you criticized as taking a long time for Rust are not actually taking a long time. My point with poking Java, specifically, is that Java is going on 30 years old and doesn't yet have an analogous feature. Moreover, since we're talking about Kernel dev, do C or C++ have a standard async runtime? Considering that there's little-to-no prior art for doing the kind of async API Rust wants without active garbage collection, I'd assert that it's hard to criticize how long it's taking. Do you know how long it "should" take? If so, how?
The lack of context is a pain. For instance, trying to open a file that doesn't exist just gives the error "file not found" without telling you the path you tried to open.
Fair enough. But that doesn't have to do with the error handling mechanism of Rust, nor would any of these error helper libraries fix that. It's just a criticism of the error type that's actually returned. A Java-style exception can be written that's just as lacking. No language that I'm aware of will automatically include function arguments in its errors/exceptions- it's up to the author of the error/exception type to include that info.
