The practical difference is that there is (partial) enforced checking of errors. If you do not wish to check the error code, you must be explicit.

    f := os.Create("output.txt")

Will give a compile error

    multiple-value os.Create() in single-value context:

and should be written as one of these:

    f, err := os.Create("output.txt")
    f, _ := os.Create("output.txt")

where the second indicates that you are ignoring the returned error.

I say "partial" because if you ignore all the return values you can implicitly ignore an error:

    fmt.Println("Hello")

It is quite common to see:

    if err != nil {
        //handle error
    }

in Go, as their philosophy is that the caller should handle the error, not an unrelated piece of code. Yes, this does sometimes look like "litter", and it doesn't really make for the most impressive code. However, you won't be surprised by it, it's simple to understand, and if something goes wrong, you'll know what, when, and what was done about it. This has been Google's opinion on C++ for a while. http://google-styleguide.googlecode.com/svn/trunk/cppguide.x... lists some pros and cons. Writing code that ignores errors is one way of writing code, I think it's idiomatic Java and Python (please correct me), but that's not the way that was chosen for Go.

I don't really use panic() except to indicate bugs:

    if playerCount == 2{
        go multiPlayer()
    } else if playerCount == 1{
        go singlePlayer()
    } else {
        panic(playerCount)
    }

However they can be useful inside libraries. For example if you call fmt.Printf("%s",s), where s has a method s.String(), will print the result of s.String(). Sound good? But what if s is a nil pointer? Well, you may wish s.String() to handle that and return "A nil s", which is fair enough. However is s.String does not handle this case it may panic(), leaving fmt.Printf to recover() and write "<nil>" instead.

http://golang.org/src/pkg/fmt/print.go#L630