That was actually one of the questions asked during the "Meet the Go team" talk at Google I/O. They joke around for a bit, but they end up giving some solid arguments.

http://www.youtube.com/watch?v=sln-gJaURzk&feature=playe...

Edit: If you're curious/interested in Go, it's worth watching the whole talk.

The answer given was that individuals can then choose how many spaces they want their tabstops set to, and this was mostly an accident not formal thought out design. (I didn't see any other arguments given.) gofmt itself is of course a very good idea.

I have been following Go along the years, but think they made a big mistake with exceptions. In particular you have to manually write the code from where an issue happens all the way to where it is handled. Exceptions as done in other languages isn't the exact pattern that has to be followed - it is the writing of the boilerplate code that bugs me. Heck they could do something as simple as if the error value returned is not used in any way then an automatic 'return ...vals..., error' is inserted after the call.

I'm curious if you have used panic/recover to see if it fills the perceived void. (I'm not saying they do, I don't know)

https://code.google.com/p/go-wiki/wiki/PanicAndRecover

http://blog.golang.org/2010/08/defer-panic-and-recover.html

http://dave.cheney.net/why-go-gets-exceptions-right

Thanks for the links, and panic is the usual retort. My problem is with the boilerplate between methods. If A calls B calls C calls D calls E which can have issues that A wants to handle (eg try a different IP address) then all the intermediary functions will need code like:

   foo,bar,err=callX(...)
   if err!=nil:
       return _,_,err

It is the last two lines of boilerplate that need to be present for virtually every call that makes me uncomfortable. Developers will start forgetting or not being diligent which causes problems. Also I think (but don't know) that by the time A gets an Error it won't know what the stack trace is for the original Error. (The stack traces are extremely useful for logging and analytics not for program behaviour.)

Needing to write the boilerplate means it is left out. For example look at all the hello world examples. Note how they all ignore any errors from the println. C has exactly the same problem, and I'm disappointed that Go is perpetuating this problem.

Go doesn't require tabs. Tabs and spaces work just like C, they separate tokens but are not otherwise relevant. It's not like Python where they indicate indentation level.

The only whitespace character that works differently than C is the newline. In Go, newlines (usually) separate statements, like a semicolon does in C.

From the topmost section:

We use tabs for indentation and gofmt emits them by default. Use spaces only if you must

Code formatting conformity is pretty big in the Go culture.

Go the language doesn't care if you use tabs or spaces, Go the community would prefer you to use tabs so when your Go code is loaded in whatever random editor any member of the community uses there are no surprises.

I only care that it was formatted with gofmt.