A strong type system gets you regularity but then you have to deal with the type system all the time (Scala). A leaner type system makes things simple, but every once in a while you have to step in and assist the type system (Go). A dynamic system can sometimes prompt you to make you own little type system. Zero sum game.
I find nothing about Go's type system quirks that would merit "warty".
The singular wart (and a tough one to remove), in my mind, is that, in general, Go's runtime makes poor use of the static aspects of the language, which is annoying given how strict the compiler appears to be at compile phase. (item: I don't mind paying the static + compile approach, but in that case, pretty please allow me to instantiate instances of types using simple string name of the type!)
I think this part of the equation needs to be tweaked, and likely will given that a combo of new library calls and a revamped runtime (you know that is the next Go story) can address this matter.
I don't mind paying the static + compile approach, but in that case, pretty please allow me to instantiate instances of types using simple string name of the type!
If go allowed that kind of "eval"-like functionality, it would be impossible to compile it down to a static binary. You would always be wondering if someone would instantiate a type that you didn't include in the binary.
Java's VM does allow creating classes from strings. It has its uses, I guess, but Go is more based around the idea of knowing the types ahead of time.
Unless you are just talking about syntax, in which case you should know that new is completely optional in most scenarios; new Foo is the same as &Foo{0}, etc.
