Hi Tom, first of all thanks for commenting and pointing out that the code blocks didn't work. I have no idea why that happened, but I re-added them and hopefully they should now re-appear for you (and stay that way).

Now to address some of your points:

Because it allows the normal code to do the happy path, and when there is trouble it switches to a separate "exception" path.

Yeah and that's great in theory, but I feel like exceptions aren't the best way to do it. Mainly, my problem is that the exception path isn't obvious. For one, I cannot look at one code snippet in isolation and know whether, if line 1 runs, line 2 will also run (since line 1 might throw an exception). I also might look at some code that throws an exception and want to understand the "exception" path. In that case, I'll not only have to look at all callers, but at the callers of those methods and so on and so forth until I find a catch around them.

Both of these are just very hard to figure out, while generally being very easy to follow using Results (or Either or Throw or whatever it's called in the different languages).

Additionally, I've often seen new exceptions being added to an existing API. Some people even treat it like a non-breaking change, because the "success" path works and it compiles. Even if it isn't, most people update some dependency and don't check whether or not new exceptions might now appear.

Not all Result implementations or usages solve that specific problem either, but oftentimes they are paired with some union type in a language that forces you handle all of the cases. You cannot do that with exceptions.

from experience the amount of if-statements needed to handle error states after a call are terrible.

With monads, you shouldn't have any if's after they are returned. (Or rather, they are very simple ones hidden inside of the Monad themselves).

Exceptions make the code so much more readable, and that is the second most important aspect of code.

I agree that readability is one of the most important aspects of code. (I'm curious what your number one is, though – that it works?)

The reference to goto is a bit weird. I get what you're saying, but exceptions follow the stack, which way less random than goto.

Yeah I know that it's weird ^^

I don't think it's as bad as goto, but it's surprising/funny how much they actually share.

But the point about "following the stack" instead of being random like gotos actually is a really good point, that I wish I had included in my article.