3 ms·

The result type is obviously insufficient for writing nontrivial programs, because nontrivial programs fail in nontrivial ways that need exceptional control flo

The result type is obviously insufficient for writing nontrivial programs, because nontrivial programs fail in nontrivial ways that need exceptional control flow. The result type does not work because you have to choose between immediate callers handling failures (they don't always have the context to do so because they're not aware of the context of callers higher up on the call stack) or between propagating all of your error values all the way up the stack to the error handling point and making your program fantastically brittle and insanely hard to refactor.

ttfkam 1y ago
The Result type works for an awful lot of people. Be careful with absolute statements like "does not work." When it works for many others, they might just assume it's a skill issue.
- throw10920 1y ago
  When I say "it doesn't work" I mean that it doesn't allow you to write good code, not "doesn't work" as in the sense that people don't like it. That latter one doesn't make any sense, as languages like PHP "work" for many tens (hundreds?) of thousands of people. I'm well aware of the tendency of Rust programmers to write bad code, constrained by the language, and then be deluded into thinking that that's good code.
  - ttfkam 1y ago
    Lord, grant me the confidence of this man who claims objective understanding of what does and does not constitute "good code".
    - throw10920 1y ago
      I note that you did nothing to refute my point about why error-handling-via-return-values is insufficient and instead resort to emotional manipulation and logical fallacies. This seems to happen a lot in the Rust community when people point out flaws in the language.
      - ttfkam 1y ago
        Why should I defend Rust? You haven't even defined "good code", which has eluded the best minds in the field for as long as the field has existed. You are not a serious person.
        throw10920 1y ago
        I don't need to define "good code" for my argument. You're not a person capable of using logic, apparently. As is characteristic of Rust zealots.
        ttfkam 1y ago
        > When I say "it doesn't work" I mean that it doesn't allow you to write good code But you skipped over how you are defining, "good code"? Without that part, "doesn't allow" cannot be evaluated in the context of Java or C++ or Python or Go or Rust. Logic.
        throw10920 1y ago
        Apparently you have difficulty with reading comprehension, because my original comment already defines "good code": > The result type does not work because you have to choose between immediate callers handling failures (they don't always have the context to do so because they're not aware of the context of callers higher up on the call stack) or between propagating all of your error values all the way up the stack to the error handling point and making your program fantastically brittle and insanely hard to refactor. It's interactions like this that are the reason why my organization isn't adopting Rust.
        ttfkam 1y ago
        Defined good code TO YOU. You've failed to recognize there is no objective and universally recognized metric for good code within our industry. The closest thing we have to it is number of defects per line of code and how severe those defects are through CVEs. That's it. You've mistaken your personal preferences and aesthetic sense for absolute truth. The arrogance is astounding.
steveklabnik 1y ago
> The result type is obviously insufficient for writing nontrivial programs Counterpoint: there are many non-trivial programs written in Rust, and they use Result for error handling.
- throw10920 1y ago
  Pointing to programs written with design flaws caused by the flaw in the programming language does invalidate the claim that the flaw exists and negatively affects those programs. You can write any program in COBOL. Most people would say that it's an insufficient language for doing so. "Insufficient" here obviously does not mean that it's impossible to write non-trivial programs, just that they'll have bad code.
nextaccountic 1y ago
You can inspect error values in Rust, handle some errors, and bubble up others, with an ordinary match statement. Exactly like try catch

ttfkam 1y ago

The Result type works for an awful lot of people. Be careful with absolute statements like "does not work." When it works for many others, they might just assume it's a skill issue.

throw10920 1y ago
When I say "it doesn't work" I mean that it doesn't allow you to write good code, not "doesn't work" as in the sense that people don't like it. That latter one doesn't make any sense, as languages like PHP "work" for many tens (hundreds?) of thousands of people. I'm well aware of the tendency of Rust programmers to write bad code, constrained by the language, and then be deluded into thinking that that's good code.
- ttfkam 1y ago
  Lord, grant me the confidence of this man who claims objective understanding of what does and does not constitute "good code".
  - throw10920 1y ago
    I note that you did nothing to refute my point about why error-handling-via-return-values is insufficient and instead resort to emotional manipulation and logical fallacies. This seems to happen a lot in the Rust community when people point out flaws in the language.
    - ttfkam 1y ago
      Why should I defend Rust? You haven't even defined "good code", which has eluded the best minds in the field for as long as the field has existed. You are not a serious person.
      - throw10920 1y ago
        I don't need to define "good code" for my argument. You're not a person capable of using logic, apparently. As is characteristic of Rust zealots.
        ttfkam 1y ago
        > When I say "it doesn't work" I mean that it doesn't allow you to write good code But you skipped over how you are defining, "good code"? Without that part, "doesn't allow" cannot be evaluated in the context of Java or C++ or Python or Go or Rust. Logic.
        throw10920 1y ago
        Apparently you have difficulty with reading comprehension, because my original comment already defines "good code": > The result type does not work because you have to choose between immediate callers handling failures (they don't always have the context to do so because they're not aware of the context of callers higher up on the call stack) or between propagating all of your error values all the way up the stack to the error handling point and making your program fantastically brittle and insanely hard to refactor. It's interactions like this that are the reason why my organization isn't adopting Rust.
        ttfkam 1y ago
        Defined good code TO YOU. You've failed to recognize there is no objective and universally recognized metric for good code within our industry. The closest thing we have to it is number of defects per line of code and how severe those defects are through CVEs. That's it. You've mistaken your personal preferences and aesthetic sense for absolute truth. The arrogance is astounding.

steveklabnik 1y ago

> The result type is obviously insufficient for writing nontrivial programs Counterpoint: there are many non-trivial programs written in Rust, and they use Result for error handling.

throw10920 1y ago
Pointing to programs written with design flaws caused by the flaw in the programming language does invalidate the claim that the flaw exists and negatively affects those programs. You can write any program in COBOL. Most people would say that it's an insufficient language for doing so. "Insufficient" here obviously does not mean that it's impossible to write non-trivial programs, just that they'll have bad code.

nextaccountic 1y ago

You can inspect error values in Rust, handle some errors, and bubble up others, with an ordinary match statement. Exactly like try catch