[ragnese]

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

[pjmlp]

Now I am the Java guy, impressive.

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.

[ragnese]

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?

[bobbylarrybobby]

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.

[ragnese]

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.

[kaba0]

You can just map the error to a tuple for example with the file name.