3 ms·

What is reporting the errors? In a standalone environment, in which you're left with the core language, anything that reports errors is something you can define

What is reporting the errors? In a standalone environment, in which you're left with the core language, anything that reports errors is something you can define, and you can define that component to use error codes, just as we would in C. It feels odd to want exact control over the error handling abstraction but want to use Rust's convenient IO abstraction. Performance either matters or it doesn't. > debate unto itself without a clear answer, but you pretend as if it's a solved problem and that your view couldn't possibly be wrong This debate was settled: we started out with error codes. We saw a generation of languages with exceptions --- Java, C++, CL with its condition system, Python, etc. arise in reaction to the problems with error codes. The current movement away from exceptions, which I think started with Go, feels like backsliding, especially because most of the justifications for error code primacy that I see either ignore the actual (instead of mythologized) costs of exceptions or claim that exceptional code is a hardship inconsistent with my experience. Now, it's possible that we should think of exceptions as just a failed experiment, but that view isn't consistent with the extreme utility I've seen in exception systems. Exceptions are so useful that people build them out of longjmp! Anyway, it's frustrating that because Rust tried to solve simultaneously for ergonomics, exception freedom, and a rich standard library, it ended up in a position of having to abort on OOM. (I realize that there are more options these days.) Still, exceptions in stdlib with an option for an exception free standalone system feels like the more appropriate trade-off. I understand that there are trade-offs everywhere, but this observation doesn't mean that I have to excuse what I see as very bad trade-offs.

burntsushi 10y ago
> It feels odd to want exact control over the error handling abstraction but want to use Rust's convenient IO abstraction. Performance either matters or it doesn't. This doesn't make any sense. What are the performance costs of doing I/O in Rust using `std::io`? If there are none, why would I want to give it up? AFAIK, the only reason to give up `std::io` is if your platform isn't supported by `std`. > it's possible that we should think of exceptions as just a failed experiment Who said that? Why does one way have to be right? There are trade offs! I'm sure you can find plenty of articles on the Internet that discuss exceptions vs. values. There are plenty of reasonable arguments on both sides. > This debate was settled OK, that's enough. I won't waste any more of my time with someone who is so certain of themselves.
- quotemstr 10y ago
  You seem to be using the fact that there are trade-offs as a justification for the specific trade offs you've made and using tone policing as a substitute for defending these trade-offs
  - burntsushi 10y ago
    If you can't acknowledge the presence of trade offs, then I don't see how I could justify specific trade offs. Just because I want to engage in a productive conversation doesn't mean my entire argument boils down to tone policing. It is OK to stop talking to someone because they are too frustrating to talk to.
    - quotemstr 10y ago
      Where did I disagree with the existence of trade-offs? What I find invalid is the idea that all trade-offs are equally good. The Rust scheme has certain advantages and certain disadvantages. I believe that the advantages don't matter much and that the disadvantages are worse than other people think. The advantages and disadvantages of the conventional C++ and Java model are better for a general purpose systems language.
      - burntsushi 10y ago
        > Where did I disagree with the existence of trade-offs? When you say stuff like this: > This debate was settled and this > I do dismiss this advantage out of hand In general, most of your comments on this topic make every possible negative point about Rust's error handling without ever taking care to balance it with the positive points. If we can't even come to a mutual understanding that there are some trade offs involved in this decision, then it's really hard to move on to balancing the trade offs. Especially when you say things like this: > All you do with "try!" is annoy readers > had its designers not jumped on the anti-exception bandwagon > without properly considering the advantages of the exception model > All of this because some people don't like exceptions This is a consistent dismissal of both the trade offs involved and of the people that actually worked on this stuff. Do you actually believe Rust is the way it is because we just hopped on a bandwagon? If so, that's extraordinary bad faith.
Manishearth 10y ago
> Anyway, it's frustrating that because Rust tried to solve simultaneously for ergonomics, exception freedom, and a rich standard library, it ended up in a position of having to abort on OOM. (I realize that there are more options these days.) ... if you realize that there are more options, please don't make this point, because the point doesn't make sense anymore. Aborting on OOM in Rust is a default, but you're not stuck to that system.
- quotemstr 10y ago
  Sure, but then we're back to exceptions in one form or another, so now we have Result all over the place and have to deal with panics. Being able to panic on OOM won't go back in time and rewrite stdlib
  - Manishearth 10y ago
    > Being able to panic on OOM won't go back in time and rewrite stdlib I don't see how that's relevant? If you have to deal with OOM you're probably not going to deal with it at a fine-grained level, you'll have one high-level panic catcher somewhere that handles this and all other panics. Given that overcommit exists as well, this makes the cases where you want workable Result-on-OOM quite niche. (And there is work -- lower priority work, but it exists -- for pluggable allocators which will let the stdlib eventually abstract over more of this)
    - quotemstr 10y ago
      Hundreds of millions of people use non-overcommit systems. That's a good thing, because overcommit is a mistake that encourages profligate use of system resources. I fear that abort-on-OOM will only reinforce the presumption of overcommit in the minds of developers. Even on overcommit systems, you can run out of address space or vsize. I believe in treating memory like any other resource. You wouldn't abort by default when you run out of disk space, would you?
      - Manishearth 10y ago
lmm 10y ago
> The current movement away from exceptions, which I think started with Go, feels like backsliding, especially because most of the justifications for error code primacy that I see either ignore the actual (instead of mythologized) costs of exceptions or claim that exceptional code is a hardship inconsistent with my experience. I don't think it comes from Go; rather it comes from the ML family (which Rust is arguably a member of). ML has had exceptions and error codes for decades, and ultimately that experience has come down on the side of error codes, because with good sum types and higher-order functions they are safer and more effective than exceptions. An analogy: early fighter planes were aerodynamically unstable, as it was hard to make them maneuverable any other way. Later fighter planes were stable as this was safer and easier to control. Modern fighter planes are aerodynamically unstable, as modern control systems can control such planes effectively and the original advantages remain.

burntsushi 10y ago

> It feels odd to want exact control over the error handling abstraction but want to use Rust's convenient IO abstraction. Performance either matters or it doesn't. This doesn't make any sense. What are the performance costs of doing I/O in Rust using `std::io`? If there are none, why would I want to give it up? AFAIK, the only reason to give up `std::io` is if your platform isn't supported by `std`. > it's possible that we should think of exceptions as just a failed experiment Who said that? Why does one way have to be right? There are trade offs! I'm sure you can find plenty of articles on the Internet that discuss exceptions vs. values. There are plenty of reasonable arguments on both sides. > This debate was settled OK, that's enough. I won't waste any more of my time with someone who is so certain of themselves.

quotemstr 10y ago
You seem to be using the fact that there are trade-offs as a justification for the specific trade offs you've made and using tone policing as a substitute for defending these trade-offs
- burntsushi 10y ago
  If you can't acknowledge the presence of trade offs, then I don't see how I could justify specific trade offs. Just because I want to engage in a productive conversation doesn't mean my entire argument boils down to tone policing. It is OK to stop talking to someone because they are too frustrating to talk to.
  - quotemstr 10y ago
    Where did I disagree with the existence of trade-offs? What I find invalid is the idea that all trade-offs are equally good. The Rust scheme has certain advantages and certain disadvantages. I believe that the advantages don't matter much and that the disadvantages are worse than other people think. The advantages and disadvantages of the conventional C++ and Java model are better for a general purpose systems language.
    - burntsushi 10y ago
      > Where did I disagree with the existence of trade-offs? When you say stuff like this: > This debate was settled and this > I do dismiss this advantage out of hand In general, most of your comments on this topic make every possible negative point about Rust's error handling without ever taking care to balance it with the positive points. If we can't even come to a mutual understanding that there are some trade offs involved in this decision, then it's really hard to move on to balancing the trade offs. Especially when you say things like this: > All you do with "try!" is annoy readers > had its designers not jumped on the anti-exception bandwagon > without properly considering the advantages of the exception model > All of this because some people don't like exceptions This is a consistent dismissal of both the trade offs involved and of the people that actually worked on this stuff. Do you actually believe Rust is the way it is because we just hopped on a bandwagon? If so, that's extraordinary bad faith.

Manishearth 10y ago

> Anyway, it's frustrating that because Rust tried to solve simultaneously for ergonomics, exception freedom, and a rich standard library, it ended up in a position of having to abort on OOM. (I realize that there are more options these days.) ... if you realize that there are more options, please don't make this point, because the point doesn't make sense anymore. Aborting on OOM in Rust is a default, but you're not stuck to that system.

quotemstr 10y ago
Sure, but then we're back to exceptions in one form or another, so now we have Result all over the place and have to deal with panics. Being able to panic on OOM won't go back in time and rewrite stdlib
- Manishearth 10y ago
  > Being able to panic on OOM won't go back in time and rewrite stdlib I don't see how that's relevant? If you have to deal with OOM you're probably not going to deal with it at a fine-grained level, you'll have one high-level panic catcher somewhere that handles this and all other panics. Given that overcommit exists as well, this makes the cases where you want workable Result-on-OOM quite niche. (And there is work -- lower priority work, but it exists -- for pluggable allocators which will let the stdlib eventually abstract over more of this)
  - quotemstr 10y ago
    Hundreds of millions of people use non-overcommit systems. That's a good thing, because overcommit is a mistake that encourages profligate use of system resources. I fear that abort-on-OOM will only reinforce the presumption of overcommit in the minds of developers. Even on overcommit systems, you can run out of address space or vsize. I believe in treating memory like any other resource. You wouldn't abort by default when you run out of disk space, would you?
    - Manishearth 10y ago

lmm 10y ago

> The current movement away from exceptions, which I think started with Go, feels like backsliding, especially because most of the justifications for error code primacy that I see either ignore the actual (instead of mythologized) costs of exceptions or claim that exceptional code is a hardship inconsistent with my experience. I don't think it comes from Go; rather it comes from the ML family (which Rust is arguably a member of). ML has had exceptions and error codes for decades, and ultimately that experience has come down on the side of error codes, because with good sum types and higher-order functions they are safer and more effective than exceptions. An analogy: early fighter planes were aerodynamically unstable, as it was hard to make them maneuverable any other way. Later fighter planes were stable as this was safer and easier to control. Modern fighter planes are aerodynamically unstable, as modern control systems can control such planes effectively and the original advantages remain.