GoRoutines you beauty.

for i:=0; i< maxValue; i++ {
    // Some very time consuming process
    res, err := http.Get("some_api.blah/blah/blah")
    if err != nil {
        log.Panic("What!")
    }
}

This codeblock will

1. stop execution when there is an error
2. Do this linear

Meh, who cares :)

for i:=0; i< maxValue; i++ {
    // Some very time consuming process
    go func(){
        res, err := http.Get("some_api.blah/blah/blah")
        if err != nil {
            log.Panic("What!")
        }
    }()
}

Voila! multithreaded code! Though, it is not a very good example :)

Interfaces.

Links explain it better than I could ever do. https://tour.golang.org/methods/9 golang.org/doc/effective_go.html

gofmt

No more arguing about how many tabs should be in a go source code file, or what is the best formatting practise for putting braces.

$ gofmt source.go > new_source.go

It gets formatted perfectly, as per standards defined by language itself. https://golang.org/cmd/gofmt/

Don't worry, most of the editors come with it, so you won't have to do it manually.

channels

Any scala/erlang developer will know what this is. The simplest explanation is, it is a pipeline which can be used to interact among goroutines.

https://golang.org/doc/effective_go.html#channels

Only Error no Exception

I guess this is disputed. People feel that there should be a try-catch block and exceptions should be propagated. IMO, handling an error when it occurs and not after "throw"ing this or that and the catching it in some layer is better. The moment you have an problem do what is needed.

It also avoids situations like these

try{
    // some things happening here
} catch (Exception ex) {
    // Some dumb idiot caught all the exceptions here
    log.error(ex.getMessage());
    throw new SomeIdioticException("");
 }

This is both a bad way to tackle an error, if there is some issue, which isn't a precursor of "SomeIdioticException" we are still catching it, and throwing an incorrect exception, makes it a very bad design.

In retrospect, Go doesn't allow you to do any such thing, if there is an error catch it there itself, and take an action.

res, err := http.Get("some-api.com/api")
if err != nil {        // I have no other choice than to handle it here
    log.Panic("Error: ", err.Error())
}      

#go-nuts

You won't find community more friendlier. freenode/#go-nuts

I find this interesting:

When iterating over a map with a range loop, the iteration order is not specified and is not guaranteed to be the same from one iteration to the next. Since Go 1 the runtime randomizes map iteration order...

Check the full page here: https://blog.golang.org/go-maps-in-action