However, it doesn't impact whether I enjoy writing Go code or not. It tends to be mitigated by blessed built in types and functions with parametric polymorphism (e.g., `map`, `[]`, `append`, `delete`, etc.) in addition to Go's structural sub-typing and type embedding. First class functions help too.
Actually, this results in a really nice aspect of Go that I've come to appreciate: reading and writing Go code tends to have very little cognitive overhead. Things tend to be very straight-forward and clear. I'm not sure if this is because there aren't generics, but I have my suspicions that it is. The language itself and its semantics is very simple and can fit in your head easily. But this is my experience, YMMV.
Dirty little secret: sometimes I cheat a little when writing small commands in Go and sacrifice compile time type safety by using my `ty` package.[1]
[1] - http://blog.burntsushi.net/type-parametric-functions-golang
The problem is Go lacks immutable data structure. I believe everybody know why immutable data structure is required. Go slice and map are all mutable-only, so to make some read-only data view, we need to write all the containers by hand. Amount of code increases exponentially.
It would be great if Go had such a immutable slice/map stuffs, but they decided not to have that due to legacy compatibility issue with existing []byte/string(which is actually just an immutable view on []byte) types.
So now the only hope is generics. I don't want to write hundreds of same list/map classes just to offer immutable views. That's all duplicated works, and I just want ability to write List<T> and Map<T>.
If you don't think immutable data structure or view is not important, Go is good enough to you. But that feature is crucial to me, and that's one of the biggest reason of why I stopped using Go.
I got a half-working solution [4] with a lot of interface{} and some reflection, but upon speaking with some of the Golang devs, the consensus was "this is not something you do in Go." From what I understand, you're expected to build a custom memoizing function for each set of datatypes you're expecting to use it for (which admittedly is not a ton of code), and generic helpers are not advised.
I can't say authoritatively whether "Go needs generics!" or not, but life has been much easier after porting my code back to Python—though a large part of it was because it was a fairly dynamic webapp which is still a pain point for Go. I hope to give Go another try soon, probably for a different project.
[0] https://pypi.python.org/pypi/dogpile.cache
[1] https://pypi.python.org/pypi?%3Aaction=search&term=cache&sub...
[2] https://pypi.python.org/pypi?%3Aaction=search&term=memoize&s...
[3] http://docs.python.org/dev/library/functools.html#functools....
To me, it just seems ugly. I like a type system where I know what a type is at each point, and there isn't some ugly "catch all" type that you can use when you run out of other options, which effectively just throws away all type information (and this is what interface{} does, as everything implements it).
public T Get<T>(int id, string cacheKey) {
}
In Go, you have to return an interface (and ideally an error)
Here would be the equivalent,
v, err := s.Get(id int, cacheKey string)
if err != nil {
//Handle error here
}
if v == nil || v.(*models.User) == nil {
return nil, http.StatusNotFound
}
interface Fooer {
func Foo()
}
type Bar struct {}
func (s Bar) Foo() {}
func (s Bar) Baz() {}
func DoFoo(f Fooer) {
f.Foo() // fine
// f.Baz() compile error
f.(Bar).Baz() // fine
}If you want a Bar specifically (as the DoFoo code does above), it should take a Bar as an argument.
If you want to accept any struct that satisfies Fooer, add all the methods to Fooer that you need them to satisfy...
Doing otherwise is just subverting the type system and you might as well use a blank interface and effectively have no type checking on your input - if you require a Fooer and then typecast someone might pass a Fooer and get a nasty surprise when it doesn't work.