[steveklabnik]

> The overall result is that everyone pays the cognitive cost of exception (spelled "unwind" in Rust) safety

Very, very few people have to think about unwind safety, because it really only comes into play when you're writing unsafe code, and relying on the ability for panics to be caught. Many folks aren't writing any unsafe, and many who are are doing it explicitly in a panic=abort environment. And most don't rely on panics being able to be caught in the first place.

So, some subset of library authors have to pay attention to unwind safety in some cases. This is hardly "everyone."

> pays the syntactic

It's one character.

> and runtime costs of error code checking,

Exceptions also have runtime costs. I'm not aware of anything demonstrating that there is a really major difference between the two in real systems. I would be interested in reading more about this! Most of the discussion I've seen focuses on microbenchmarks, which can be very different than real code.

> pays the runtime cost of unwind tables,

Only if you want them, as you yourself mention, you can turn this off. And many do.

[edflsafoiewq]

> It's one character.

No it isn't. With exceptions:

  fn foo() -> i32 {
    let x = bar();
    x + 1
  }

vs

  fn foo() -> Result<i32, SomeErrorType> {
    let x = bar()?;
    Ok(x + 1)
  }

[steveklabnik]

This is fair, thank you for the correction.

I do think it's not quite what you're saying though, due to Rust's design, we would have checked exceptions, and so the Result part would be there with exceptions, it's the Ok() part that would change.

In theory you could make a language without checked exceptions that would make it be like your example.

[steveklabnik]

Okay so, technically in theory you can introduce logic bugs, but not memory safety bugs, if you don't consider unwind safety in safe code. Logic bugs can happen in any code, of course.

The practical, day-to-day implications of this still round to zero, though.

[quotemstr]

> The practical, day-to-day implications of this still round to zero, though.

Vendors have been using similar language to downplay potential bugs for decades, usually to disastrous results. At one point, even memory safety wasn't a big deal. I'm just waiting for a software package to have a security vulnerability when an attacker is able to trigger an untested Rust unwind path and put some Rust daemon into a state it didn't expect.

There are many good parts of Rust, but I don't think I'm ever going to convinced that the error handling wasn't a huge and unfixable mistake. It's because error handling is such a big mistake that Rust has grown layers of syntactic sugar --- try!, !, etc. --- to paper over the ugly spot in the language.

[steveklabnik]

Again, I am only speaking of logic bugs here. You cannot introduce memory safety bugs without unsafe code.

> I don't think I'm ever going to convinced that the error handling wasn't a huge and unfixable mistake.

That's fine. No language can satisfy everyone.

[quotemstr]

Logic bugs can be just as disastrous as memory safety bugs. From an attacker's point of view, they're ultimately about making a program do something not intended. Downplaying logic bugs (where Rust is weak) and emphasizing memory safety (where Rust is strong) might make Rust look better, but it's not doing any favors for computing.

[steveklabnik]

I agree that they can be. There are a few differences:

1. It is not clear that we will ever be free of logic bugs to the same degree that we can minimize memory safety bugs.

2. We're in a specific context in this sub-thread, and that's that you claimed that this is a pervasive issue that everyone must consider all the time. These logic bugs can only be introduced in a context that is very unusual, and so my claim is not that logic bugs in general are irrelevant, but that the context that this kind of bug can appear is smaller than you say it is.

> logic bugs (where Rust is weak)

Rust gives you way more tools than C to reduce logic bugs as well.

[quotemstr]

The whole point of secure programming is caring about those "unusual" contexts. And the comparison to C isn't really fair: C is dangerous for everything. Yes, Rust is better than C, and even better in some ways than C++, but my point is that there's another Rust out there, a Rust^, that's even better than Rust, and Rust^ uses exceptions for error handling throughout.