It is important to disentangle a number of issues here. What about Go, Rust and Erlang? Indeed, what about them? This article is about the problems of Java’s checked exception-handling mechanism in the context of Java programming (it is, after all, for the book 97 Things Every Java Programmer Should Know), so interesting as these languages and their approaches are, they are not relevant in this context because (1) they do not have checked exceptions, (2) they do not have exceptions, and (3) they are neither Java nor like Java.

Exceptions very much satisfy the principle of “fail fast and loud”, and that is their raison d’être going all the way back to CLU. What you are conflating here is the idea “fail fast and loud”, which is a runtime property, with the idea of something being expressed and checkable in the type system.

In the three languages you mention, “fail fast and loud” is a runtime property and not a strongly checked compile-time property. In Go, error conditions are signalled using return values, which can be ignored. The situation is similar in Rust, although unused return values will generate a warning. Erlang is a dynamic language with an optional type system (which applies to functions, but not messages).

I consider the advice on offer in my article to be the most practical for any Java programmer contemplating whether to make an exception checked or not.