> I'm sorry you lost me after your outrageous claim that one must learn everything about the standard types of Go before one can program effectively. I can't

> I'm sorry you lost me after your outrageous claim that one must learn everything about the standard types of Go before one can program effectively. I can't help but be amused to see the complaint that Go's type system is, of all things, too complex. At the time I first picked up Go, Racket was my favorite language of choice[0]. One of the biggest things I noticed about Go was how little I needed to think about types and implementation. Part of this was simply having a static typechecker[1], but part of it is how the rest of the tooling is designed as well. > How many people programming with Go pass arrays around? Most people using Go shouldn't be using arrays at all, since they really don't fit most use cases (fixed size and size is part of the type). [0] For the record, I still like Racket, but I've found I'm undeniably far more productive in Go. [1] Type Racket exists, but at least at the time, most libraries were untyped, which meant I had to write typed wrappers for everything.