Concurrency in Rust • Hacker News Board

Re: Concurrency in Rust

#91

Post by quotemstr » Sun, Mar 27, 2016, 7:10 PM UTC

Rusky wrote: post #87

quotemstr wrote: post #79

Earlier quoted context omitted.

> why is panic-ing bad, but an exception good? Because the Rust people don't believe in making "catch" a first-class primitive in the language, and in fact, fully support a runtime option to turn all panics into aborts. Even if abort-on-panic were to be killed as a legal mode of operation, and even if the stigma were to be removed from std::panic::recover, we'd still be left with a language with two error handling st…

Exceptions can be turned into aborts in C++ as well, and are in many types of programs, because exceptions do have downsides for some problem domains. If Rust forced exceptions on everyone, there'd be people complaining about that just like you're complaining now. I see the split between `Result` and `panic!` as more like Java's split between checked and runtime exceptions, except `Result` is much more usable than ch…

> Exceptions can be turned into aborts in C++ as well,

No you can't. -fno-exceptions does not appear in the C++ standard. You can write a compiler for any language. C++-that-aborts-on-throw is not C++, although, sure, it's closely related.

The ability to turn off C++ exceptions was a temporary workaround for compiler deficiencies in the 1990s that snowballed into an extremely harmful schism that's still doing tremendous damage to the C++ community.

The difference between -fno-exceptions and Rust's abort-on-panic is that the former is an unofficial, disgusting hack, while the latter is getting full official support for some reason.

Re: Concurrency in Rust

#92

Post by quotemstr » Sun, Mar 27, 2016, 7:11 PM UTC

Rusky wrote: post #90

quotemstr wrote: post #86

Earlier quoted context omitted.

> Sure, but if linux has this issue, then C++ programs on linux will also have this issue Why even bring Linux into the discussion? A Rust program running on Windows has the same problem. > No. My point was simply that no language has a complete solution to this problem. A correct C++ program running on Windows will not spuriously abort. Neither will a C++ program running on a Linux system configured not to overcommi…

...and the same is true of Rust, just with different defaults. Switch allocation failure from an abort to a panic and catch the panic just like you would in C++. What's incomplete about that? It's not like C++ can't be switched in the other direction with -fno-exceptions or equivalent.

-fno-exceptions is not part of C++. C++ is not whatever GCC and Clang happen to accept.

Re: Concurrency in Rust

#93

Post by quotemstr » Sun, Mar 27, 2016, 7:13 PM UTC

psi-squared wrote: post #88

quotemstr wrote: post #79

Earlier quoted context omitted.

> why is panic-ing bad, but an exception good? Because the Rust people don't believe in making "catch" a first-class primitive in the language, and in fact, fully support a runtime option to turn all panics into aborts. Even if abort-on-panic were to be killed as a legal mode of operation, and even if the stigma were to be removed from std::panic::recover, we'd still be left with a language with two error handling st…

There is an exception-like mechanism in Rust, in the form of the "try!" macro. It's a lot more flexible, but somewhat more verbose (Haskell has the same mechanism in a way that looks a lot more like exceptions, so that's not an inherent flaw). The best explanation I've seen is this: http://www.jonathanturner.org/2015/11/learning-to-try-things... tl;dr: "Result"s are like exceptions which are caught by default. You ca…

> There is an exception-like mechanism in Rust, in the form of the "try!" macro.

Correct. That's not the problem. If Rust's standard library returned Result in all cases where allocation could fail, I'd be satisfied. My primary issue is that they didn't, because Result is awkward.

Rust's designers went wrong in trying to have their cake and eat it too. They wanted to avoid exceptions and not make people care locally about errors. That's why they assert that errors just don't happen and abort if they do.

Throwing exceptions is a reasonable design choice. Returning error codes is a reasonable design choice. Pretending errors don't exist is not.

Re: Concurrency in Rust

#94

Post by Manishearth » Sun, Mar 27, 2016, 7:17 PM UTC

quotemstr wrote: post #89

Manishearth wrote: post #85

Earlier quoted context omitted.

> Because the Rust people don't believe in making "catch" a first-class primitive in the language, and in fact, fully support a runtime option to turn all panics into aborts. recover() exists. You're right, there's a stigma to it, because you're not supposed to use it unless you really need to (hence, no programmer confusion). It's supposed to be used for situations like: - Catching panics before crossing an FFI boun…

The problem with the dualistic error handling strategy you're proposing is that the "severe" path gets even less testing than normal error recovery schemes do. Imagine you're working with a big non-exceptional C++ codebase (e.g., Firefox) and somebody throws std::bad_alloc. Even if you don't abort immediately and let the exception unwind the stack, the unwinding process will still leave lots of invariants broken, sin…

Note that recover() uses Rust's type system to enforce certain things about exception safety. It's harder to mess up, even if libraries are written without unwinding in mind.

Re: Concurrency in Rust

#95

Post by quotemstr » Sun, Mar 27, 2016, 7:18 PM UTC

Manishearth wrote: post #81

quotemstr wrote: post #75

Earlier quoted context omitted.

No custom allocator can make a task that fails to allocate gracefully report an error. Rust's error handling design is just terrible, and mostly a consequence of eschewing exceptions. Had Rust opted for exceptions, it'd be a much better, and actually usable, language. Rust's terribly error-handling strategy is the chief reason not to use it.

> and mostly a consequence of eschewing exceptions. A panic is the same thing as an exception. If you want to catch a panic, use recover(), it's meant to be used exactly for these end-of-the-world panic scenarios (and for FFI/etc). You can plug in a custom allocator that panics on OOM (I think the standard one aborts). As Steve mentioned, custom allocators can mean two things. The type that exists in rust today is on…

> A planned extension will let you have allocators with different semantics entirely work with stdlib types

And what about all the code that doesn't? It's because so much code exists that's completely oblivious to the possibility of these stdlib functions failing that I don't think that merely adding the option to do the right thing is good enough. The existing failure-oblivious APIs need to be explicitly deprecated.

The only ways to redeem Rust is to either support exceptions as first-class citizens with mandatory runtime support or to convert all existing allocating stdlib functions to return Result and mark all the existing failure-oblivious ones as being as deprecated as gets(3) in C.

Re: Concurrency in Rust

#96

Post by burntsushi » Sun, Mar 27, 2016, 7:41 PM UTC

quotemstr wrote: post #93

psi-squared wrote: post #88

Earlier quoted context omitted.

There is an exception-like mechanism in Rust, in the form of the "try!" macro. It's a lot more flexible, but somewhat more verbose (Haskell has the same mechanism in a way that looks a lot more like exceptions, so that's not an inherent flaw). The best explanation I've seen is this: http://www.jonathanturner.org/2015/11/learning-to-try-things... tl;dr: "Result"s are like exceptions which are caught by default. You ca…

> There is an exception-like mechanism in Rust, in the form of the "try!" macro. Correct. That's not the problem. If Rust's standard library returned Result in all cases where allocation could fail, I'd be satisfied. My primary issue is that they didn't , because Result is awkward. Rust's designers went wrong in trying to have their cake and eat it too. They wanted to avoid exceptions and not make people care locally…

> Pretending errors don't exist is not.

We don't and we never have.

Re: Concurrency in Rust

#97

Post by Rusky » Sun, Mar 27, 2016, 7:42 PM UTC

quotemstr wrote: post #95

Manishearth wrote: post #81

Earlier quoted context omitted.

> and mostly a consequence of eschewing exceptions. A panic is the same thing as an exception. If you want to catch a panic, use recover(), it's meant to be used exactly for these end-of-the-world panic scenarios (and for FFI/etc). You can plug in a custom allocator that panics on OOM (I think the standard one aborts). As Steve mentioned, custom allocators can mean two things. The type that exists in rust today is on…

> A planned extension will let you have allocators with different semantics entirely work with stdlib types And what about all the code that doesn't? It's because so much code exists that's completely oblivious to the possibility of these stdlib functions failing that I don't think that merely adding the option to do the right thing is good enough. The existing failure-oblivious APIs need to be explicitly deprecated.…

Even C++ doesn't have mandatory exception support, and even Rust can catch panics from failure-oblivious code.

Re: Concurrency in Rust

#98

Post by lambda » Sun, Mar 27, 2016, 7:42 PM UTC

galonk wrote: post #59

steveklabnik wrote: post #37

Earlier quoted context omitted.

I am in the middle of working on a second draft of the book. This page is one of the oldest bits of docs, overall, and isn't my best work. It's not _wrong_, I just have very high personal standards. It was adapted from older documentation and was written in the time up to 1.0, where I had a LOT on my plate.

It certainly is _confusing_ if not _wrong_. You silently add "move" to the closure without any mention or explanation (then later say "note that we're copying i" without explaining that you're talking about the "move" keyword). The bit about Mutex also has a "just type this to fix the problem with no explanation of how or why it works" flavour (although I guess if you already grok mutexes then its use here might be o…

  Rust tutorials always spend a lot of time interpreting 
  Rust's notoriously poor error messages

I'm wondering where you got the sense that Rust's error messages are "notoriously poor." Can you expand on that?

I have always found Rust's error messages to be quite good. Of course, they can be hard to interpret occasionally if you don't already grasp the concepts they are referring to. But I don't see any way to solve that in error messages; at some point, you have to learn enough about the language for the error messages to make sense. And occasionally, the suggestion they provide for how to fix the issue isn't the right suggestion, but I don't know if there's a way to always do that without strong AI that understands what you mean. The best you could hope to do is to provide suggestions for all of the possible fixes, though that could lead to some messages that are too verbose to the point of being useless.

I think it would help to provide some examples of error messages you have had trouble with, to help figure out ways to make them better.

Re: Concurrency in Rust

#99

Post by quotemstr » Sun, Mar 27, 2016, 7:42 PM UTC

steveklabnik wrote: post #83

quotemstr wrote: post #79

Earlier quoted context omitted.

> why is panic-ing bad, but an exception good? Because the Rust people don't believe in making "catch" a first-class primitive in the language, and in fact, fully support a runtime option to turn all panics into aborts. Even if abort-on-panic were to be killed as a legal mode of operation, and even if the stigma were to be removed from std::panic::recover, we'd still be left with a language with two error handling st…

This is an area where you just can't actually please everyone. I have heard the same opinions you've expressed in this thread, just as strongly, for even including unwinding at all. That aborts should be the only option, and that the cost of unwinding is far too high to be included in a true systems language. Language design is tough. I'm glad we have multiple languages.

It's _because_ Rust tried to please everyone that it painted itself into this corner. If the exception people had won, life would have been great.

But if the error-code people had won, then life would still be good, because then Rust's stdlib might have been a bit uglier, but it would at least be correct with respect to error propagation. It's because Rust tries to satisfy both camps --- because it tries to give you the concision of exception code and, er, the lack of actual exceptions --- that it's forced into the terrible position of needing to abort internally on error, lacking a way to report errors to higher level code.

The lesson here is that optimizing for happiness and harmony leads to bad design.

Re: Concurrency in Rust

#100

Post by quotemstr » Sun, Mar 27, 2016, 7:45 PM UTC

Rusky wrote: post #97

quotemstr wrote: post #95

Earlier quoted context omitted.

> A planned extension will let you have allocators with different semantics entirely work with stdlib types And what about all the code that doesn't? It's because so much code exists that's completely oblivious to the possibility of these stdlib functions failing that I don't think that merely adding the option to do the right thing is good enough. The existing failure-oblivious APIs need to be explicitly deprecated.…

Even C++ doesn't have mandatory exception support, and even Rust can catch panics from failure-oblivious code.

> Even C++ doesn't have mandatory exception support

Yes it does. That some compilers provide a way to disable mandatory language features is no argument.

> even Rust can catch panics from failure-oblivious code.

Not while maintaining that code's invariants it can't.