The principle behind Go's design decision is based on actual experience and need to be understood by amateurs. The idea is quite simple: errors are not some ra

The principle behind Go's design decision is based on actual experience and need to be understood by amateurs. The idea is quite simple: errors are not some rare special cases, they are ordinary, general events. That means there are no need to some special mechanism for handling them. They should be handled as ordinary events within common FSM. There is no contradiction in using the general mechanism of examining returned values to determine the state of procedure execution. Any FSM requires if (or cond) statements. It is the essence of a program's logic. The mechanism of exceptions was wrong. It is wrong in Java, it is wrong in C++. It is just a bad design. The good design is using the same mechanism the underlying OS uses. In case of UNIX-derivatives it is the explicit checking of a return value. Because errors are common and ordinary events. Amateurs believe that errors are rare, and they will avoid them. This is over-optimistic - in practice errors are of nothing special. It is just an alternative branch of a condition, where a consequent assumed to be a success.