Why Go will kick ass in your next project

Site is down for me (timeout). Here is the Google cache link: http://webcache.googleusercontent.com/search?sclient=chrome-...

Go has been great to learn. I was initially very annoyed that Go has no classes but I've found interfaces to be extremely powerful. I had two wow moments:

1. When I realized I could write a http response using anything that accepted an io.Writer (a struct with a compatible Write() method). I can use fmt.Fprint and pass http.ResponseWriter as the first parameter. Need a new line? Don't concat an \n, just use Fprintln.

2. Go has a number of interfaces such as sql.DB (database/sql). Even though Go doesn't provide SQL access directly, it standardizes SQL access and means if a library fizzles out or I write a new one from scratch, I can drop mine into an existing project with almost zero changes -- This meant choosing an SQL driver was very easy, I was reassured that if I picked the wrong one, fixing that would be easy as long as I picked one that built upon sql.DB.

Go seems to be very cleanly designed.

I have yet to have a wow moment with slices. Looking forward to it!

Aside: many of these articles extol the virtues of static linking. I'm pleased that it is being re-discovered via Go. It was always unfairly overlooked from a deployment standpoint of desktop apps ("what if we need to upgrade just this library for a security fix?").

If you only deploy on a single node, there is no obvious advantage (beside not fearing an update of a shared library might break your code). But if you deploy on a cluster, you might have an advantage, especially if that cluster is somewhat heterogenous (not the same version of OS, not the same libraries, etc.).