Hacker News Reader

> I don't understand the need to enforce the use of { } and that the if of for line must end with a {. I don't like this writing. My preferred syntax is the one of Pythons, which is the most concise and clear.

This article explains the reasoning behind lots of Go's design choices: http://talks.golang.org/2012/splash.article

"Some observers objected to Go's C-like block structure with braces, preferring the use of spaces for indentation, in the style of Python or Haskell. However, we have had extensive experience tracking down build and test failures caused by cross-language builds where a Python snippet embedded in another language, for instance through a SWIG invocation, is subtly and invisibly broken by a change in the indentation of the surrounding code. Our position is therefore that, although spaces for indentation is nice for small programs, it doesn't scale well, and the bigger and more heterogeneous the code base, the more trouble it can cause. It is better to forgo convenience for safety and dependability, so Go has brace-bounded blocks."

My personal opinion on the subject is that you should not obsess about those things. It is good that Go that enforces one consistent style. In practice it does not really matter for your productivity what that style is.

That said, I don't consider this a convincing argument. They basically say "We had some problems in the past with embedding Python code in Java files". This is a very specific problem and I could think of at least 4 different specific solutions for this specific problem. I don't think this arguement can support very broad conclusions like "Spaces for indentation does not scale to big and heterogeneous code bases and compromises safety and dependability for convenience".

> My personal opinion on the subject is that you should not obsess about those things. It is good that Go that enforces one consistent style. In practice it does not really matter for your productivity what that style is.

My qualm with Go here is that it does not enforce a consistent style. (note: I use Go quite frequently). Trailing semicolons, parentheses, curly braces should either be valid or invalid. There are instances in the languages where either is fine.

A particular style is enforced automatically by go fmt.

There are many cases of style that are not.

Its convinced if you consider that Go was made to solve most of Google's problems.

The formatting has been well thought out. The main problems with Python formatting are copy and paste problems, source control merges, and relying on the count of invisible characters to determine indenting. Any time you're merging two bits of code, it's very easy for the indenting to get messed up. In go, that's not a problem, since the braces are the only thing that matter. This is also what allows gofmt to format your code for you.

I think you misunderstand slicing. It's very similar to python's slices, except that python makes a copy of the list and Go does not. This is a really nice feature for reducing data copies.

The default values are very useful in many situations, and code is often designed around the fact that uninitialized variables have specific values.

As for error handling, Go's error handling is one of its biggest strengths, in my opinion. You never have to worry that your function will exit out in the middle unexpectedly. This is really great when dealing with third party libraries, since you don't have to know if something 6 levels deep is going to throw an exception... if something returns an error, you can deal with it right there. I find I write much more reliable code in Go, because error handling is so much simpler.

I find that the braces and termination policy forcibly avoid stuff like:

   for p = initial; p.next != nil; p = p.next;
       doSomething(p);

This is a whole class of pain I've had to debug before. Better to be explicit.

I'm not really a fan of python indentation as I've had to clean up a couple of messes before.

So use Nimrod instead: systems programming with indentation based syntax. It also has unmatched meta programming facilities, a realtime GC and checked exceptions done right (however, not in the 0.9.0 release).

Interesting, I hadn't heard of it before: http://nimrod-code.org/

It looks it could be another language to use for writing native code across iOS, Android and Windows.

Indeed. In fact Nimrod has already been used on Android (http://forum.nimrod-code.org/t/61#319) and iOS devices.

> The way Go handles errors looks original and interesting, but I'm lacking experience to determine how it compares to exceptions from the usage perspective.

Having done a lot of straight C programming in my life, the error handling in Go is very familiar. Most C code returns errors and doesn't use exceptions (though I have used setjmp()/longjmp() fairly successfully at times).

In practice, the code is more verbose with Go's style of returned errors, but requires you to think more explicitly about errors and recovery, resulting in potentially better code overall.

However, since Go doesn't have an RIAA like C++ and doesn't have "goto" like C, it makes cleaning up from errors more ugly and repetitious (and potentially error prone). File handling, in particular, is causing me headaches right now (getting files closed on errors). I am admittedly a Go newbie, so I may be missing some style that makes it cleaner.

Getting files closed on errors should look something like:

    file, err := os.Open(filename)
    if err != nil {
        // handle the error however you see fit
    }
    defer file.Close()
    // continue working, knowing that file.Close() will be called when the surrounding function returns

See: http://golang.org/doc/effective_go.html#defer

Ah! Thanks! I had seen panic/recover but hadn't caught "defer". That will make my code much better.

"defer" is 50% of the reason I use Go. Open some resource, then defer close it the next line and move on. No more giant, nested try/finally blocks.

In addition to defer, Go actually does have goto.

I find it acceptable, since they did away with semi-colons, which always offended me a lot more than braces.

...since they did away with semi-colons, which always offended me a lot more than braces.

The semi-colons are still there, but in most cases they can be inserted automatically when the program is being compiled.