> cheapFunction(...) || expensiveFunction(...)
is not valid unless both functions return bool
> car = car || "bmw"
is not valid at all, because both types would need to be bool
> funcA(...) && funcB_WhichMightBreakWithoutFuncA(...)
not valid unless functions return bool. I think Go smartly realized this syntax is just sugar that causes more problems than it solves.
We can debate the merits of truthiness and using it this way, but let's have that debate on the merits, not by invoking other languages with completely different design constraints.
Your argument here is similar to what got us "no split infinitives" in English (grammarians wanted English to be more like Latin).
"Because Go doesn't support it" would also be a reason to avoid:
* Generics (at least until recently)
* Classes
* Prototypes
* Exceptions
* Async/Await
* Package managers (until recently)
* Algebraic data types
* Effect types
* Type inference
* Type classes
* Etc.
You could argue that one or more of these are footguns, but I seriously doubt you'd consider them all to be, so let's talk about what separates the footgun from the feature that just didn't fit in Go's design.
Something tells me you'd hate my five-line implementation of the standard library function fgets in C.
char *fgets(char *buf, size_t n, FILE *fp) {
char *p = buf;
int c = 0;
while (n > 1 && (c = getc(fp)) != EOF && (*p++ = c) != '\n')
n--;
return n > 0 && (c != EOF || feof(fp) && p != buf) ? *p = '\0', buf : 0;
}