[cratermoon]

Anyone that can wrap their mind around the model of Communicating Sequential Processes[1] implemented using channels in Go will improve their programming. See also Concurrency is not Parallelism by Rob Pike: https://www.youtube.com/watch?v=oV9rvDllKEg

After I figured it out, I spent a good month writing personal projects to play with channels and concurrency and get the "these are cool I'm going to use them everywhere" urge out of my system.

1 http://www.usingcsp.com/

[verdverm]

Interfaces and the Go way of using them is arguably more important than CSP, as the former can apply to all code while the latter is only needed for concurrent code. The Go talks have many great gems, GopherCon talks too

[cratermoon]

Interfaces are great, and easier to understand than Go's concurrency. Maybe the hardest part is getting the idea that neither interface nor implementing code need to know anything about the other.

Here's a fun experiment: dig through your codebase and find all the public methods, then look at the signatures and find the top 3-5 most common constructs. Now define an interface using those. Perhaps not very useful, but interesting to see. I bet a comprehensive audit of Go code in the wild (not including the standard libraries) would find a lot of types implementing something like this this:

    type StringHandler interface {
        Handle(string)
        Parse(string)
        Count() int
    }