3 ms·
The thing about simplicity is making the language simpler often makes programs themselves more complex. For example, in a language without generics, if you have
by School-Cotton 2y ago
The thing about simplicity is making the language simpler often makes programs themselves more complex. For example, in a language without generics, if you have 10 different versions of the same function that only differ by a type parameter, you have to either write them 10 times (meaning anyone reading the code has to read 10 different functions), or you have to write some code generator (meaning anyone reading the code has to now understand your code generator). And, all this cost in the complexity of programs is to avoid something that, in my opinion, _barely_ makes the language any more complex.
So you're not uniformly increasing simplicity. I do agree that when there is a way to make a language simpler without any other downsides (e.g. making programs more complex or error-prone), it should always be done!
Most people, even Go programmers, would think it was silly if you couldn't define your own functions and had to copy-paste blocks of code everywhere, so clearly they aren't against abstraction in principle. And I don't think generics is a particularly more complex form of abstraction than the ability to define functions is! The fundamental difference is not the level of abstraction, but just that _it didn't exist in C_, and the version of it in C++ (templates) is extremely difficult and unwieldy. So presumably that's what the designers of Go were afraid of.
> One question I ask in earnest, why do people not just use another language rather than try to get features jammed into Go?
I have to use Go because I am working in an ecosystem that is entirely in Go. Rewriting it in another language would be much more effort than is feasible. When I work on personal projects not for work I don't use Go at all.
Also, not everyone uses Go because it lacks features for abstraction; there are other reasonable reasons to use it, for example if one likes the Goroutine-style concurrency model.
- cherry_tree 2y ago> For example, in a language without generics, if you have 10 different versions of the same function that only differ by a type parameter, Can you give an example of why you would need to do this? I use go everyday and have never had multiple copies of the same function as described here.
- School-Cotton 2y agoThere are tons of examples. So here's a random one: a function that sorts an array. You either need generics, need to write it using runtime polymorphism (making it significantly slower), or need to re-write it for every type of element that you want to sort an array of. The fact that Go has functions called sort.Strings, sort.Floats, sort.Ints, etc. is just silly duplication that wouldn't have happened in any other modern language.
- cherry_tree 2y agoWouldn’t you just use sort.Slice? Doesn’t go having such type specific functions mean you don’t have to? Feels like that makes your codebase _less_ complex since the core logic is handled by the language stdlib, not code written and maintained by your team.
- IshKebab 2y agoSorting using generics is faster and more ergonomic. That's why they are adding generic based sort to the standard library. https://pkg.go.dev/golang.org/x/exp/slices#Sort https://pkg.go.dev/golang.org/x/exp/slices#Sort Sort on its own is maybe not the best example because it's relatively easy to work around, but those workarounds quickly break down. Write me a function that returns the keys of a map in order without using generics... I'm not exactly sure what your second point is.
- cherry_tree 2y agoBut go isn’t a language without generics, so I don’t understand the criticism
- Capricorn2481 2y agoWell you were quoting a part that said "in a language without generics" and were questioning why that was bad, so that's what they responded to. But that used to be Go, and it got a lot of pushback when generics were introduced. It illustrates an issue people have where obviously good language features are rejected by a loud minority for seemingly no good reason.