That's all well and good, but entirely irrelevant to the number of options a JVM should reasonably have.

I don’t believe the Go compiler would reject unformatted code. The compiler has its own set of rules for what it views as syntactically correct code, but these rules have nothing to do with gofmt’s formatting rules.

For example, it’s the compiler and not gofmt that dictates that you must write a curly brace only on the same line of an “if” statement. If you put it on the next line, you don’t have unformatted code - you have a syntax error.

However, the compiler doesn’t care if you have too much whitespace between tokens or if you write your slice like []int{1, 2,3,4}, but gofmt does.

We could say the rules of the compiler and gofmt don’t even overlap.

They do worry, they just can't do anything about it. Like the fact that error handling code takes at least three lines no matter how trivial it is. I'm sure error handling would not be critisized nearly as much if it didn't consume so much vertical space and could fit in one line, which go compiler does allow.

We also don't in other ecosystems, Go advocates pretend we do.

C has had indent since 1976, then it is only a matter of having a pre-commit hook, regardless of the programming language.

We don't need some monk telling us how to format code from the gospels, a company wide rulling suffices.