1. I'll just handle all of the errors by having my functions return Result<T, E> where E is some type that encapsulates all of different error conditions that can happen in my function.
2. Function one returns Result<T1, E1> and function two returns Result<T2, E2>. What type do I use for a function that calls both and just uses `?` to defer handling on errors from either function? Guess I either have to use Box<Error> and do a bunch of ugly downcasting whenever I want to handle an error or I have to write a bunch of code to define another error type E3 which combines E1 and E2 and I have to implement From<E1> and From<E2> so now I have more code just for defining error types and conversions than I have for actually doing anything.
3. Create complicated macros like error_chain[1] or failure[2] to try to cut down on boilerplate in #2.
Yes, that's the monadic equivalent to `catch(E1 e) {handle e}; catch(E2 e) {handle e}; catch(E3 e) {handle e}...`
On practice things get all over the place, with some times the exception being more concise and other times they being way more verbose. But the problem to be solved is not verbosity, it's with implicit code catching you by surprise, with too generic handlers on code that can't reasonably handle an error, and some issues with how errors interfere with code composition.
This is... not at all true? Rust already has the `?` operator, and there's no indication of this being replaced with do notation or anything like it.
Do you have any citation for this? That’s not my experience at all.
The part about people panicking everywhere is hyperbole (on the mood of the article). I've seen more panics than it makes sense and resorted to them too on disposable code, even they being more up-front work than handling it correctly.
That sounds more like laziness on the part of the programmer, rather than the language design.
Good languages account for this, and make the best choice the easiest choice whenever possible. If the best choice is twice as much work, there will be a lot times when the language encourages the programmer to do something else. I don't consider this a fault on the part of the programmer, I consider a fault on the part of the language.
I bet this generalization is wrong
1 - Exceptions do suck. It's obvious in Haskell where there are better tools but sometimes you aren't allowed to use them.
2 - Rust thus goes into: well, let's take those better mechanisms and allow them everywhere. Go goes into: well, let's create some alternative mechanism like the ones most people are used to.
3 - Rust then goes into: oops, our error handling does not stack well so people are just panicking everywhere (what actually requires more code than proper handling). Go goes into: oops our error handling requires 2 times as much code as the actual program, so people are just panicking everywhere.
4 - Rust will eventually solve its crisis by creating something equivalent to "do" notation. I don't really think there's any solution for Go, but I do expect them to create some low level exception system so they can keep the language simple - maybe this time they'll copy VB instead of C.
By the subject of your point #6, Rust's mechanism is strictly more powerful than exceptions. It can do anything exceptions do, and more. Go's evidently is not.