3 ms·

While so many people are complaining about what it doesn't have, The problem is not really what Go does not have, it's that often fallacies are used to react t

While so many people are complaining about what it doesn't have, The problem is not really what Go does not have, it's that often fallacies are used to react to critique on Go. Another one that pops up very often is 'you just have to use it for some time to understand why Go does not need it'. This is of course nonsense. Anyone who has programmed C and C++ knows the advantages and disadvantages of generics. And despite the disadvantages of a particular implementation, most people want still want generics for good reasons. Even if you like Go (and I do mostly), it's ok to say 'sure, that is a weakness in the current version of Go'.

jerf 12y ago
Read what I linked. I'm not afraid to anti-recommend Go for given use cases. That said, since you mentioned it, I'll reiterate what's in that link to observe that "Go doesn't have generics" is a half truth. (And I don't mean "lie"... it has non-trivial truth in it. But it is only a half-truth.) Generics are a complicated concept that encompasses at least "generic data structures" and "generic algorithms"; you can slice and dice in other things, too, but it certainly has at least those two aspects. The former I freely admit is an uncovered case, and I still believe is something Go needs to address sooner or later. The latter is covered in Go via the interfaces. I think the reason why Go in practice doesn't need a lot of generic data structures is that its core use case, concurrent network servers, has an awful lot of byte streams flowing around, and, lo, the code I'm converting into Go has a lot of byte streams flowing around. A bajillion "generic data structures" don't much help with that use case. (Now, the natural contrarian argument here is to talk about how you might need them someday, but, seriously, you probably don't need them all the time. If you do... don't use Go.) The "generic algorithms" concept is incredibly useful, but, lo, Go actually supports it fairly well. On first read of the Go feature set it's really easy to blip over the "implicit satisfaction of interfaces" and think it's an irrelevant parlor trick, but in practice it's really very useful in surprising and profound ways.

jerf 12y ago

Read what I linked. I'm not afraid to anti-recommend Go for given use cases. That said, since you mentioned it, I'll reiterate what's in that link to observe that "Go doesn't have generics" is a half truth. (And I don't mean "lie"... it has non-trivial truth in it. But it is only a half-truth.) Generics are a complicated concept that encompasses at least "generic data structures" and "generic algorithms"; you can slice and dice in other things, too, but it certainly has at least those two aspects. The former I freely admit is an uncovered case, and I still believe is something Go needs to address sooner or later. The latter is covered in Go via the interfaces. I think the reason why Go in practice doesn't need a lot of generic data structures is that its core use case, concurrent network servers, has an awful lot of byte streams flowing around, and, lo, the code I'm converting into Go has a lot of byte streams flowing around. A bajillion "generic data structures" don't much help with that use case. (Now, the natural contrarian argument here is to talk about how you might need them someday, but, seriously, you probably don't need them all the time. If you do... don't use Go.) The "generic algorithms" concept is incredibly useful, but, lo, Go actually supports it fairly well. On first read of the Go feature set it's really easy to blip over the "implicit satisfaction of interfaces" and think it's an irrelevant parlor trick, but in practice it's really very useful in surprising and profound ways.