3 ms·
I have pretty mixed feelings about them. My opinion hasn't changed dramatically since they've been released--they make certain things easier, and they lead to p
by throwaway894345 4y ago
I have pretty mixed feelings about them. My opinion hasn't changed dramatically since they've been released--they make certain things easier, and they lead to people overcomplicating things. I also don't care for the dict-based implementation--it makes it considerably harder to reason about performance tradeoffs.
Mostly though, most of the stuff people were complaining about regarding Go's lack of generics were really minor things, like map/filter versus for loops. There are some things you really couldn't do easily in Go without generics, but for the most part Go's critics were just obstinate about not wanting to learn a new style of programming (so much so that many are willing to forsake all of Go's considerable advantages with respect to tooling, deployment model, build times, package management, ecosystem, etc). Moreover, Go's critics were (and still are) unwilling to admit there are benefits to avoiding generics--the code becomes less abstract and more standard as there are fewer ways to express a given solution.
If you really want to dunk on Go, the more valid criticism is that it lacks sum types, and unlike converting a map/filter chain to a for loop, there is no good way to emulate sum types in Go (there are some tricks to get close, but they involve far more boilerplate and they don't give exhaustiveness checks (and the performance tradeoffs suck).
- seer-zig 4y agoWhat you mention as considerable advantages might apply for someone coming from Python or Ruby. For many of us in Java or C# land, what they have is already much better.
- kaba0 4y agoOkay, sum types. Let’s say you want to implement an optional type, how would that look like with sum types? `Nothing` is okay, but `Some` needs to somehow mark the wrapped object’s type, so you also need generics here.
- throwaway894345 4y agoYou don’t need to implement a generic option type. It’s easy enough to implement ad hoc like we do/did with linked lists pre-generics.
- kaba0 4y agoAnd then you just cast everywhere? Doesn’t sound too ergonomic.
- throwaway894345 4y agoNo, you just define it ad hoc locally. type OptionInt enum { Int(int), None } Yeah this means you would have to write that line for every type, but that’s pretty in-line with Go’s philosophy that a little bit of copying is better than a little dependency. But the people who optimize for keystrokes above all else will take issue with it.
- kaba0 4y agoThat’s probably the only amount of copying that might be okay. Anything more than that and you have n places of code living independently of each other, making refactoring/bugfixing impossible.
- throwaway894345 4y agoYes, if the code is complex, this becomes tedious. But you'd be surprised how often this sort of thing suffices. It turns out not everything needs a dozen combinator methods. See also a linked list implementation: `type List struct { Next *List, Item int }`.