Hacker News Reader

Comment by xucheng | Hacker News Reader

Compared with Rust’s Result monad, which allows developers to clearly see the effects of error handling, there are two other hidden fallible effects in Rust that are much harder to tackle:

* Panic rewinding. I am not sure how to ensure your Rust function being panic safe. It is quite easy to cause soundness issue if some invariants no longer hold due to panic. I see `PanicGuard` sometimes used in Rust std library.

* Future cancellation. `tokio::select` is one of the infamous examples, where it is quite easy to introduce bug if the future cannot handle cancellation gracefully.

When trying to handle them properly, it feels more like writing traditional C code than Rust.

View on HN

>I am not sure how to ensure your Rust function being panic safe.

You could use the linking trick in which your panic handler uses non-existent extern fn. For example, this approach is used in the no-panic crate. Of course, this approach is nothing more than a clever hack with several significant limitations.

>Future cancellation

I would say it's a more general problem of Rust lacking linear types.

IMHO both panics and async are a mistake. The latter should be a standard library with some macros and the former should be replaced by proper error handling everywhere.

Yes out of memory errors should be able to be handled. You might not care when writing web backend slop designed to run under orchestrators but for systems code it is necessary sometimes and Rust is a systems language.

It’s possible to work around both shortcomings but they contradict the languages mission and are warts. Async is a big “excessive cleverness” mistake.

It is not possible to implement async/await efficiently and safely with macros, and so doing so would be “contradicting the language’s mission.”

They were considered and even originally built that way, but empirically it was worse.

I’d go further and say it’s not possible to fully implement async/await without compiler help.

I got really far with stateful, back in 2016 [1]. Stateful was an attempt to write a coroutine library in a proc macro, which generated state machines, as opposed to using os primitives like green threading. This was back before the rust community really started working in this space. I ended up extracting the type system from rustc to do much of the analysis, but it ultimately failed due to how difficult it was to output rust code that respected the borrow checker rules. I also didn’t have anything like the pinning system, so I couldn’t catch move issues either.

It was a much better idea to just implement this in the compiler.

[1]: http://erickt.github.io/blog/2016/01/27/stateful-in-progress...

Hmm… didn’t know they tried.

Personally I just loathe async in general. Go has it right, but I understand why you can’t do that in Rust. Async is an ugly workaround for the inefficiency of OS threads, and I wish they would just fix that so we can stop all this madness.

Reply on news.ycombinator.com