That's probably more a matter of taste. Go has a reflect package which allows the programmer to determine type at runtime, making generics unnecessary.
It may not be as convenient and familiar as generics.
Here is an example http://play.golang.org/p/a18VESulWS
>That's probably more a matter of taste. Go has a reflect package which allows the programmer to determine type at runtime, making generics unnecessary.
That's not "making generics unnecessary". That's "using an ugly hack that throws typesafety away instead of a proper solution".
And it's more familiar than generics, that's what Java had before they understood that they had to have generics.
Well, you are right it reminded me of method overloading. Otherwise I think time will tell. In the end generics are just types with parameters, for creating typed permutations _at_compile_time_ of functions/maps etc.. And as you said, java worked quite a while without them.
Sorta. It's false that it has no exceptions - there's panic/recover. But idiomatic Go relies on error codes and checking the second return value of a function. As a result, Go code tends to be littered with if-statements that each check the result of a function and usually bail out with an error if an error occurred.
It's fugly, but it's fugly by design. The philosophy is that if you want reliable programs, than error conditions should be explicitly handled, right there in the source code, so you know you've covered everything you need to cover.