> And gofix, while nice, isn't really a substitute for language and standard library stability
I agree with you in principle but practically, gofix (+ gofmt) it is pretty darn close. I revisited a Go project that I wrote back when it first came out (in other words, an ancient one :). Biggest pita was dealing with the 'error' changes that gofix couldn't fix (and some minor pain due to time and Duration), but everything else was taken care of by the tool.
In any event, my understanding is that the Go authors will strategically depend on gofix to deal with language evolution (beyond "Go 1").
I've been coding since '82 and have had my share of PLs. Go is a serious contender and I highly recommend it to anyone looking for a "modern" C.
I agree with you in principle but practically, gofix (+ gofmt) it is pretty darn close. I revisited a Go project that I wrote back when it first came out (in other words, an ancient one :). Biggest pita was dealing with the 'error' changes that gofix couldn't fix (and some minor pain due to time and Duration), but everything else was taken care of by the tool.
In any event, my understanding is that the Go authors will strategically depend on gofix to deal with language evolution (beyond "Go 1").
I've been coding since '82 and have had my share of PLs. Go is a serious contender and I highly recommend it to anyone looking for a "modern" C.