3 ms·

> While the language itself looks fine, I find the community a bit off-putting I have wondered now and then about how the Rust community culture might have dam

> While the language itself looks fine, I find the community a bit off-putting I have wondered now and then about how the Rust community culture might have damaged the language. In particular, I've said for many years that Rust botched error handling by eschewing exceptions yet including panics anyway, leading to a doubling of the error handling infrastructure (you pay for both error objects and stack unwinding support) and the inability of the standard library to survive allocation failure. It's an unfixable mistake, although the language designers have walked it back the best they can over the years, culminating in the current yeet proposal. Did Rust end up with both errors and panics because the community suppressed robust debate in the name of kindness and "safety"? Was the current approach a way to try to make everyone happy without conflict?

fwungy 3y ago
As someone learning the language on production code I must agree that the error handling of Rust is terrible. Exceptions have never been a struggle point for me with other languages, but Rust error handling has literally given me headaches.
ssokolow 3y ago
> Did Rust end up with both errors and panics because the community suppressed robust debate in the name of kindness and "safety"? Was the current approach a way to try to make everyone happy without conflict? I've been hanging around /r/rust and poking at other venues since at least 2013 and my understanding was that the exception-like appearance of panics arose organically from: 1. Let's have monadic error handling for catchable stuff and an ASSERT equivalent for bugs that cannot be reasonably handled. 2. Our ownership system and mutex poisoning allows us to make strong guarantees about where invalid state is observable. Let's let a thread ASSERT without taking down the whole program. 3. It'd be nice to have RAII cleanup on an ASSERT 4. It'd be nice to have automatic diagnostics on an ASSERT failure 5. Gee, it's really awkward to have to spawn a thread in order to be able to translate an ASSERT failure into an error code when we're exposing a C API from Rust code. Let's add catch_unwind. (std::panic::catch_unwind didn't get stabilized until Rust 1.9.) The clearest expression of this is that libraries cannot opt back into unwinding when the application that depends on them sets panic=abort. If an application says "I have no need to continue with the following job/request/etc. after a programming error in a single unit of work", the libraries it depends on aren't allowed to countermand that and, if they try, it's their fault for abusing panics. Panics are overgrown ASSERTs, not an underbuilt exception system.
Georgelemental 3y ago
Unwinding is optional, and not available on all platforms that Rust supports (including WebAssembly). The language made the right choice here IMO. Lack of faillible allocation in the stdlib is a major issue, but it's also fixable.
riskable 3y ago
Other replies have made excellent points but I'd also like to point out that in the world of Rust the only time you want your code to panic is when something irrecoverable (at a very low level) happens. Like if you're messing around with bare metal/embedded stuff and you just set a (hardware) register but for whatever reason that call failed so now you can be guaranteed that the rest of your code just can't work. It's panic time! If a crate is using panic because it encountered bad input or whatever then the crate isn't doing things in a rusty sort of way. Even if it's a wrapper around an unsafe C library that uses panic everywhere the language has tools to work around that which is not the same thing as having made an inherent, unfixable mistake in the design of the language (by having more than one way to deal with errors).
Taywee 3y ago
Actually relying on panics for unwinding in any way is not encouraged in any way, and compiling with `panic = 'abort'` is really common, and completely removes all stack unwinding support.

fwungy 3y ago

As someone learning the language on production code I must agree that the error handling of Rust is terrible. Exceptions have never been a struggle point for me with other languages, but Rust error handling has literally given me headaches.

ssokolow 3y ago

> Did Rust end up with both errors and panics because the community suppressed robust debate in the name of kindness and "safety"? Was the current approach a way to try to make everyone happy without conflict? I've been hanging around /r/rust and poking at other venues since at least 2013 and my understanding was that the exception-like appearance of panics arose organically from: 1. Let's have monadic error handling for catchable stuff and an ASSERT equivalent for bugs that cannot be reasonably handled. 2. Our ownership system and mutex poisoning allows us to make strong guarantees about where invalid state is observable. Let's let a thread ASSERT without taking down the whole program. 3. It'd be nice to have RAII cleanup on an ASSERT 4. It'd be nice to have automatic diagnostics on an ASSERT failure 5. Gee, it's really awkward to have to spawn a thread in order to be able to translate an ASSERT failure into an error code when we're exposing a C API from Rust code. Let's add catch_unwind. (std::panic::catch_unwind didn't get stabilized until Rust 1.9.) The clearest expression of this is that libraries cannot opt back into unwinding when the application that depends on them sets panic=abort. If an application says "I have no need to continue with the following job/request/etc. after a programming error in a single unit of work", the libraries it depends on aren't allowed to countermand that and, if they try, it's their fault for abusing panics. Panics are overgrown ASSERTs, not an underbuilt exception system.

Georgelemental 3y ago

Unwinding is optional, and not available on all platforms that Rust supports (including WebAssembly). The language made the right choice here IMO. Lack of faillible allocation in the stdlib is a major issue, but it's also fixable.

riskable 3y ago

Other replies have made excellent points but I'd also like to point out that in the world of Rust the only time you want your code to panic is when something irrecoverable (at a very low level) happens. Like if you're messing around with bare metal/embedded stuff and you just set a (hardware) register but for whatever reason that call failed so now you can be guaranteed that the rest of your code just can't work. It's panic time! If a crate is using panic because it encountered bad input or whatever then the crate isn't doing things in a rusty sort of way. Even if it's a wrapper around an unsafe C library that uses panic everywhere the language has tools to work around that which is not the same thing as having made an inherent, unfixable mistake in the design of the language (by having more than one way to deal with errors).

Taywee 3y ago

Actually relying on panics for unwinding in any way is not encouraged in any way, and compiling with `panic = 'abort'` is really common, and completely removes all stack unwinding support.