Plus, && and || are symbols which makes them stand out from variable names. This is, in my opinion, a benefit. Admittedly, though, I prefer {} to block delimiters over begin/end and their like.

That's 10 minutes where I could be... you know, living my life, man. Everybody knows what + does. You don't have to teach a high schooler that "if A or B" means "if either A or B is true". They just get it. But what the heck does "if A || B {}" mean?

Actually, you do have to teach most high schoolers (actually most people) what "A or B" means. The common usage reads that as "A xor B"

A very good point. I still think it's a big win if it makes it 1% easier for new programmers to understand.

I actually think "and" and "or" make it 1% more difficult for new programmers because it doesn't implicitly warn them about things like short-circuit evaluation and whatnot. "and" and "or" have a lot of nuances that experienced programmers take for granted that a new programmer won't know until they're taught.

'+' is damn near universal. '&&' && '||' !universal.

They're not universal, but they're essentially so; pretty much everyone who's used C(++), Java, C#, ... has seen && and ||, and knows what it is. And people who've only used languages with 'and' and 'or' will only take a few minutes to get up to speed (they have the option of spending longer complaining about it if they want).

I don't think the argument is that people can't understand '&&' and '||', but that using 'and' and 'or' is a better choice.

So what do you do about the bitwise and and or operations. How should they be expressed?

Python expresses the bitwise and and or using the & and | characters, the exact same characters as Go.

And that also explains why Go chooses to use && and || for and the logical and or operators.

The code is much more readable if the bitwise operators do not look almost identical to the logical ones.

> people who've only used languages with 'and' and 'or' will only take a few minutes to get up to speed

No. Cognitive overhead. You pay for it every time you parse these words in your brain. You pay for it by reducing the number of nested/combined clauses that you can parse on the fly.

(This is far from the only readability issue with Go, by the way, and you're right in that it's among the more superficial ones. The language is designed so well in all ways except the one that matters the most, it hurts.)

No, laziness.

&& is pronounced "and" but actually means "shortcircuit left-to-right-evaluated and".

If you're coming from a Pascal (or non-programming) background, you do not assume either left-to-right evaluation order, nor short circuit evaluation.

The cognitive overhead is always there, because whether you like to admit it or not, programming is applied math, and exact meaning is very important;

e.g.:

    if a == 0.0 or b/a > 3 then launch_missile();

Without the "cognitive overhead of knowning guaranteed left-to-right + short circuit", this code is wrong.

The hypothetical "newbie programmer who can write a working program but has cognitive overhead deciphering &&" is a mythical creature that does not actually exist.

I agree with you, but FWIW, if you're already used to C, then the cognitive overhead of && and || is probably negligible. Given Go's pedigree, that doesn't seem too surprising.

Thank you for expressing it so eloquently.

they are, unfortunately you need to have paid attention at school when they taught you logic operators