There are some good points in there, but it doesn't help his case that he writes some of the Go examples in an unnecessarily contrived way. The first snippet can be rewritten as:
import (
"io"
"log"
"os"
)
func main() {
var (
r io.Reader
err error
)
if len(os.Args) > 1 {
r, err = os.Open(os.Args[1])
} else {
r = os.Stdin
}
if err == nil {
err = io.Copy(os.Stdout, r)
}
if err != nil {
log.Fatal(err)
}
}
EDIT: One more quip:
> I’ve always thought that the developers at Google are hand picked from the brightest and best on Earth. Surely they can handle something a little more complicated?
The point of Go is to ask if they really really have to. In my experience, there is much value to be found when colleagues can jump into your code for a drive-by contribution and start being productive on the first day.
You can try for more runtime type safety (except it's still unityped), if you also use generic function call. Still ugly however, but at least usage is somewhat sane (even if compiler still won't inform you about errors).
package main
import (
"fmt"
"reflect"
)
func Reduce(array interface{}, initial interface{}, callback interface{}) interface{} {
arr := reflect.ValueOf(array)
memo := reflect.ValueOf(initial)
f := reflect.ValueOf(callback)
for i := 0; i < arr.Len(); i++ {
memo = f.Call([]reflect.Value{memo, arr.Index(i)})[0]
}
return memo
}
func main() {
list := []int{1, 2, 3, 4, 5}
result := Reduce(list, 0, func(initial int, value int) int {
return initial + value
})
fmt.Println(result)
}
The design philosophy of Go is all about practicality - it's about helping programmers write programs quickly and easily with the least friction from the language. In my opinion it excels at that. For my money it's the easiest language to crank out real programs productively and enjoyably. And that's what really matters to me when I'm programming.
> I’ve always thought that the developers at Google are hand picked from the brightest and best on Earth. Surely they can handle something a little more complicated?
The point of Go is to ask if they really really have to. In my experience, there is much value to be found when colleagues can jump into your code for a drive-by contribution and start being productive on the first day.