They seem pretty universal to me. For example, the tedious error handling in Go that is mentioned is a turn-off to a lot of developers. Safety and speed are both things most languages strive for, and if Rust is not THE fastest or THE safest language, it’s on the efficient frontier of the two.
Exceptions are invisible though? (unless you're using checked exception in Java, which nobody does and neither python nor C++ offer). I've personally found unexpected exceptions being thrown to be one of the main causes of unreliability in production applications I've worked on. Of course you can have a blanket catch statement so it doesn't entirely crash your app, but that doesn't compare to the Rust experience where those errors almost never happen.
> I've personally found unexpected exceptions being thrown to be one of the main causes of unreliability in production applications I've worked on.
Python has a serious problems with this. Not only are exceptions not documented, they are also thrown by normal execution, so you can't just say "something serious happened here, go to the recovery".
Emil has been working in Rust for eight years. Hardly a honeymoon phase.
As for your accusation of lying: I cannot imagine where you’ve pulled that from. Emil’s description of unchecked exceptions as invisible errors insofar as you can’t see where errors might occur from the source code alone is objectively an accurate and reasonable description.
Agreed, checked exceptions surface potential errors to the caller. In that regard Java fares better. However, handling exceptions still require a separate catch clause rather than being part of the normal flow. Furthermore, it is nigh impossible to rely on checked exceptions alone, most Java code may throw RuntimeExceptions such as NullPointerException or ArrayIndexOutOfBoundsException and there is no way to know it by just looking at the calling code.
> However, handling exceptions still require a separate catch clause rather than being part of the normal flow
Only if you want to catch (handle) it. If you don't want to do that, just declare it in your "throws" clause and enjoy writing your code with the (guaranteed) assumption that you are using a valid value.
> Furthermore, it is nigh impossible to rely on checked exceptions alone, most Java code may throw RuntimeExceptions such as NullPointerException or ArrayIndexOutOfBoundsException and there is no way to know it by just looking at the calling code.
That's a bug, not a feature. These errors are often unrecoverable, hence why they are runtime and not checked.
This is personal preference of course, but exceptions are essentially "on error GOTO foo". They never resonated well with me either, since the control flow is muddled once you introduce exceptions.
> "invisible errors"
If you read further on you get the author's justification for this claim:
auto result = foo().bar();
> As a reader, I can't see where potential errors can occur. Even if I look at the function declaration for foo and bar I won't know whether or not they can throw exceptions [...]
Do you disagree with the reasoning reasoning this?
Except for the maybe simplest variable initialization, I always assume that if it exists, it may error. “Won’t error ever” doesn’t exist in the real physical world.
(See also: halting problem.)
The “invisibility” of errors in languages that have first-class exceptions usually means that exceptions are being somehow swallowed without being handled properly. Shit happens, and the program happily chugs along regardless, sowing destruction.
If you get down to reading the code, you can usually see if it is likely to error out or not. At the point where you get down to reading the code, it’s usually quite clear unless intentionally obfuscated.
A better question is, can a machine show you if the code may error and how, given language X? In statically compiled languages, IDEs have been wickedly good at inferring the possible exception types on any line of code for the last decade, even if you don’t annotate them in the signature.
