Agreed, I read the first half thinking You know, I kind of agree, but it would 'trigger' most of my colleagues - then I started thinking Oh I wonder if you could build something into mypy like rust's Result<Ok, Err> (I realise that's not rust's invention, probably haskell's?, but it's rust that made me more familiar with the concept) - then I got there in the article, great!

"Typing failure modes, not just successful returns" or something would sound like a much more appealing article to a much wider audience.

Thanks, my idea was to state the problem and propose a solution. Hope, that you will find `returns` helpful.

One risk with the title is that it doesn't convey that it's actually proposing a solution instead of being one of many "$languagefeature is bad" articles. I personally also found the problem statement presentation not all that convincing and almost closed the tab before reaching the interesting section, which is why I made the comment above.

I'm sorry, but from my perspective - a java developer that has moved to scala - this "let's drop checked exceptions for Either[Exception, T]" stuff... stinks.

And for one specific reasons: Exceptions are not important per se, but also for the stacktrace they take with them, and that is given to you when you need to handle it.

I lost too much time in this last month trying to decipher where the hell stuff happened looking at the stacktraces in the logs.

Coming back to the python approach: I like python :) and it's philosophy it's to have unchecked exception, with all what it concerns. The idea is that if you don't know an exception, you really don't know what to do. So let the code blows up - ideally in tests :) - and understand what realistically can happen and how to deal with it.

Thanks for the solution! It's elegant and is a great fit for my current work which involves retrofitting my codebase with type annotations.