Sorry, right, just because I can read (one) machine language it doesn't mean everyone can!

I should have continued - if this were true, then assembly language would be the clearest language, and then C after that.

I feel you're deliberately avoiding the point that we use high level languages to reduce verbosity, to get rid of meaningless boilerplate.

I can express in ten lines of Python what it would take 100 lines of C++ and 1000 lines of assembly language. That's why I never write in assembly language anymore except in an emergency.

----

Let's go through a real-world example which uses automatic propagation of error and see how it would work in Go.

My current work project is almost 7200 lines of code with a great deal of error checking.

There are a huge number of possible exceptions due to things out of our control - network errors, one of our machines being down for a bit, websites we're crawling that are down, errors in formatting on one specific page, changes in a site's format, operator error on our part, bad queries from the front end, we have encountered all of these and handle them rationally.

But there are only 36 places in the whole code, about once for each 200 lines, that deal with error handling, and only a couple of them are more than a few lines long.

Most of these exceptions propagate from the bottom level all the way to near the top where they are caught.

I get this propagation without having to type anything at all in my programming language which is... C++? Python? Ruby? Javascript? Java? C#? Amazing how many languages offer automatically propagated errors!

(It's Python.)

Typical exceptions are thrown from about four levels deep, but three and five happen too.

If an exception were thrown from four levels down, in Go this would correspond to four if statements checking return codes at four different levels, and only doing anything other than returning at the top level.

That would mean that if this were Go, there would be at least 144 places where I had to deal with errors, and 3/4 of the time, in roughly 108 of them, I would be doing nothing useful except checking if the error were there, and if so, returning it.

(And it could be worse from that, because the same error from the bottom might have multiple paths to propagate to the top.)

What value would those 100 "if error/return" offer in my code? Just clutter and friction and more chances for me to make a mistake.