←back to thread

Matt Godbolt sold me on Rust by showing me C++

(www.collabora.com)
611 points LorenDB | 4 comments | 06 May 25 17:51 UTC | HN request time: 0.003s | source
Show context
dvratil ◴[06 May 25 18:20 UTC] No.43908097[source]▶
The one thing that sold me on Rust (going from C++) was that there is a single way errors are propagated: the Result type. No need to bother with exceptions, functions returning bool, functions returning 0 on success, functions returning 0 on error, functions returning -1 on error, functions returning negative errno on error, functions taking optional pointer to bool to indicate error (optionally), functions taking reference to std::error_code to set an error (and having an overload with the same name that throws an exception on error if you forget to pass the std::error_code)...I understand there's 30 years of history, but it still is annoying, that even the standard library is not consistent (or striving for consistency).

Then you top it on with `?` shortcut and the functional interface of Result and suddenly error handling becomes fun and easy to deal with, rather than just "return false" with a "TODO: figure out error handling".

replies(24): >>43908133 #>>43908158 #>>43908212 #>>43908219 #>>43908294 #>>43908381 #>>43908419 #>>43908540 #>>43908623 #>>43908682 #>>43908981 #>>43909007 #>>43909117 #>>43909521 #>>43910388 #>>43912855 #>>43912904 #>>43913484 #>>43913794 #>>43914062 #>>43914514 #>>43917029 #>>43922951 #>>43924618 #
throw10920 ◴[08 May 25 04:03 UTC] No.43922951[source]▶
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.
replies(3): >>43926942 #>>43927962 #>>43934548 #
ttfkam ◴[08 May 25 15:19 UTC] No.43926942[source]▶
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.
replies(1): >>43926986 #
throw10920 ◴[08 May 25 15:22 UTC] No.43926986[source]▶
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.

replies(1): >>43927217 #
ttfkam ◴[08 May 25 15:39 UTC] No.43927217[source]▶
Lord, grant me the confidence of this man who claims objective understanding of what does and does not constitute "good code".
replies(1): >>43927487 #
throw10920 ◴[08 May 25 16:01 UTC] No.43927487[source]▶
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.

replies(1): >>43927845 #
ttfkam ◴[08 May 25 16:29 UTC] No.43927845[source]▶
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.

replies(1): >>43927963 #
throw10920 ◴[08 May 25 16:38 UTC] No.43927963[source]▶
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.

replies(1): >>43929980 #
ttfkam ◴[08 May 25 18:58 UTC] No.43929980[source]▶
> 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.

replies(1): >>43932349 #
1. throw10920 ◴[08 May 25 23:24 UTC] No.43932349[source]▶
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.

replies(1): >>43940294 #
2. ttfkam ◴[09 May 25 19:42 UTC] No.43940294[source]▶
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.

replies(1): >>43941777 #
3. throw10920 ◴[09 May 25 23:08 UTC] No.43941777[source]▶
> 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.

replies(1): >>43955099 #
4. ttfkam ◴[11 May 25 16:58 UTC] No.43955099{3}[source]▶
You've certainly demonstrated something, though likely not what you intended.