> 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.
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.
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.
> 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.
This is a bad choice to have to make. If you believe otherwise, you are an incompetent software engineer. Full stop. These are not personal preferences or aesthetics - these are facts. If you can't parse why these are bad, then you're incapable of basic logic.
> within our industry
Of course, we can already see that because you're resorting to fallacies instead of addressing the point itself.
> You've failed to recognize there is no objective and universally recognized metric for good code within our industry.
Literally none of that is relevant to the point that I'm making. I don't have to define "good code" in order to point out that something is "bad code".
I'm going to print out this thread and show it to anyone who says that they're considering learning Rust as a warning that this is what the community is like - incapable of using logic, unwilling to admit the slightest fault in their religion despite factual evidence to the contrary, and willing to use dishonest rhetoric and fallacies in their defense.
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.