Python's approach has always been highly pragmatic. Go's is as well, but with somewhat different goals. The Go team's goal seems to involve putting together a clean-enough syntax with fast-enough for systems programming performance combined with powerful-enough high-level concurrency model. They don't want to win the gold in any one category. They're going for the decathalon!

In any case, language syntax should always take into account the expectation of programmer communities. If you push syntax too far, you lose too many people.

The point of my example was simple - Go's gross mishandling of whitespace is a permanent trap for the unwary and a huge liability for people coming from other languages.

When D was nascent, many people proposed various schemes for making semicolons optional. I think it's great D didn't fall for such.

Name one language that doesn't have "a permanent trap for the unwary and a huge liability for people coming from other languages."

tu quoque fallacy -- the worst possible form of argument FOR something.

Only a fallacy if it's an argument for something. It's actually a criticism of your criticism. Oh hey, you tried to spin my comment with a different meaning. I guess you're guilty of an entirely different fallacy.

I don't really follow what in your example shows "gross mishandling of whitespace".

The most popular languages are C, C++, Java and C# and Go's syntax is very similar to those. If anything, Python is the weird one in how it treats the whitespace and hence most likely to confuse people coming from other languages.

As to optional semicolon elision - what is the problem with that? They make the code cleaner looking and gofmt will remove them for you even if you forget due to C/Java reflexes. I don't see the downside of making them optional.

Please make sure you give the example a close read, as it surprises even experienced Go programmers. Both examples look similar to code in the likes of C, C++, Java, and so on, _except_ the semantics gets radically changed depending on one line feed, which is very unlike those languages. I hope this clarifies things.

> I don't really follow what in your example shows "gross mishandling of whitespace".

That truly speaks poorly of you.

OTOH, the problem can easily be fixed by requiring a statement to contain at least one token.

The problem is that the code looks correct for anyone coming from C, C++, Java, D, Javascript, etc., but produces unexpected results.

It's an interesting way to enforce K&R indentation style.

That statement takes considerable license with the word "interesting" and practically reverses the meaning of "enforce".

yay, every Allman indented program will silently fail

I wrote a lot of code of C/C++ and my implicit assumption is that C syntax is serviceable. Since I don't see C syntax (or JavaScript syntax or Java syntax) as a major problem and Go is an improvement over those, I don't see Go syntax as a major problem.

I agree with you that Python's syntax is cleaner but I would like to bring few novel syntax-related things that Go did that are not as commonly known and in some cases are improvements even over Python.

In general I don't like deep indentation and Go has few things to help keep indentation to a minimum.

1. defer statement

In Go you can say:

  f := os.Open("myfile.dat", ...)
  defer f.Close()

That guarantees that f.Close() will be called at function exit. In Python/Java/C# to get the same guarantee, you would have to use try/finally block, introducing additional indentation for the code using f.

2. Syntax for defining methods on interfaces

  func (p *MyClass) Method(int i) {
    return p.x + i
  }

The equivalent in Python would be:

class MyClass(): def Method(i): return this.x + i

Again, less indentation.

3. panic()/recover() way of handling fatal errors also doesn't introduce additional indentation level like try/catch blocks.

If you like defer's or panic's savings on indentation, you're in desperate need of D: http://www.digitalmars.com/d/2.0/statement.html#ScopeGuardSt...

Doesn't the Go compiler flag as an error the fact that there's no "{" after the "if(blah())"? (On the same line, I mean.)

To answer my own question: No, it doesn't.