Lack of generics does not ease development speed. Generic programming is about safe reusability. (Development speed includes the test, debug, fix cycle).
No generics actually harms code clarity and destroys type safety.
No generics actually harms code clarity and destroys type safety.
The official stance on that issue is: yeah, but it's better than the hassle of supporting generics (compiler effort, object code size/slowness, and excessive high-level abstraction (a bad thing in the Go world).
I have a foot on both sides: I miss generics when I'm writing one-off low-scalability code, but it's nice to have the speed of low-level Go code, and perversely fun to actually spend some of my coding time writing all those low-level sorting and array-building routines that are the meat of programmer interviews.
Now, when a candidate asks "When will I need to write a method to sort the keys of a map?", I can answer "Every time you use a map[string]T for a novel T!"
I hate novel T now. (<-- This is also a design feature of Go, the passive pressure to not use large hierarchical types, and try to do your work with just maps and slices of primitives)
It's actually clearer as to what's going on since slices are a language primitive. They are simple and extremely transparent. This is absolutely not the case with Java's collections library or the C++ STL.
It wouldn't be a trade-off if there weren't situations where generics are really useful. But this rings more like an armchair criticism of Go than a criticism from someone who's written some Go programs. For my part, I wish languages like Java were less hostile to arrays.
If this is 'armchair criticism' why do Go's designers say they are considering adding generics support?