4 ms·

I guess I'm part of that cult as I value simplicity greatly. Heck I was even against generics and iterators, though the former has grown on me a bit. One ques

I guess I'm part of that cult as I value simplicity greatly. Heck I was even against generics and iterators, though the former has grown on me a bit. One question I ask in earnest, why do people not just use another language rather than try to get features jammed into Go? There are so many good ones out there now, it feels like a person can choose something to their own liking. If it's being forced at work, I guess that makes some sense, but I'm also a big proponent of 'when in Rome.'

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 ago
    There 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 ago
      Wouldn’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 ago
        Sorting 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 ago
        But go isn’t a language without generics, so I don’t understand the criticism
GaryNumanVevo 2y ago
You value simplicity because all of the complicated and painful code (mostly as a fault of Go's shortcomings) have been abstracted away from you.
- silisili 2y ago
  I guess that depends on your definition of simplicity. I don't think of simplicity as 'easy to do' or 'less lines of code', but in terms of easy to immediately understand what the code in question is doing, both from explicitness of said code and size of language. Perhaps I should have used 'readability.'

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 ago
  There 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 ago
    Wouldn’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 ago
      Sorting 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 ago
        But go isn’t a language without generics, so I don’t understand the criticism

GaryNumanVevo 2y ago

You value simplicity because all of the complicated and painful code (mostly as a fault of Go's shortcomings) have been abstracted away from you.

silisili 2y ago
I guess that depends on your definition of simplicity. I don't think of simplicity as 'easy to do' or 'less lines of code', but in terms of easy to immediately understand what the code in question is doing, both from explicitness of said code and size of language. Perhaps I should have used 'readability.'