They seem to take a lazy approach to feature development. Generics are complicated and bad, but having makeIntMap or makeStringSlice is...not great for develope

They seem to take a lazy approach to feature development. Generics are complicated and bad, but having makeIntMap or makeStringSlice is...not great for developer productivity. So let's special case `make()`, slices, channels, etc. so that some productivity is possible. Then as they add library features they violate their own tenants as they find utility in these verboten constructs. Exceptions are bad...But we have panics which are in no way the same thing renamed. Never expose them outside a package...But closing an already closed channel panics. Random number generator functions panic on mundane and expected things, just like Java checked exceptions. Example: https://golang.org/pkg/math/rand/ https://golang.org/pkg/math/rand/ ``` func (Rand) Int31n func (r Rand) Int31n(n int32) int32 Int31n returns, as an int32, a non-negative pseudo-random number in [0,n). It panics if n <= 0. ``` Standard behavior would be returning an error, not panicking, See this: https://blog.golang.org/defer-panic-and-recover https://blog.golang.org/defer-panic-and-recover ``` The convention in the Go libraries is that even when a package uses panic internally, its external API still presents explicit error return values. ``` It's just an inconsistent and, quite frankly, disappointing language outside of goroutines and its interfaces. Those two make it possible to be productive, but with generics for instance a whole slew of new possibilities will emerge. The simplicity is nice, but it's too simple and too inconsistent. All the verbosity of Java combined with the impenetrable inconsistency and abbreviations of C.