5 ms·

This is not the first time I argue this case, but I would go a step further and say that not having generics is feature of Go. There are plenty of languages ou

This is not the first time I argue this case, but I would go a step further and say that not having generics is feature of Go. There are plenty of languages out there with Generics. I use several of them. I use Go when that suits me, and it's typically for cases where high readability trumps doing a lot of magic with generics. I think only once or twice have I thought to myself, "this would have been better with Generics".

deskamess 6y ago
The introduction of generics would not change your workflow though. You could still happily "not use it" and keep matters readable. Others who wanted it, would use it.
- lkramer 6y ago
  Mostly concerned about having to read other people's code that uses it.
  - coldtea 6y ago
    If others people code uses it, then those other people deemed it useful. So the argument for not having them now becames either: (a) they rather not have it available, because you personally don't find it useful (b) those using generic don't know what they're doing, and only people not using generic are smart, so it's better to not have them to prevent the clueless from being able to use them
    - lkramer 6y ago
      Like I said, I use (and like) several languages that have Generics, and when I need to do something where it makes sense, I can reach for those. For me there was an advantage in having a language where it wasn't an option. Your (b) scenario is quite a strawman. I have seen plenty of good code using Generics, but sure, there is subset of code written using Generics that is not good, and I think it becomes easier to obfuscate code and make it hard to read if you have Generics, that might just by my bias, and I think I'm tainted from C++ and hopefully it will never become as bad as what you can encounter there. I'm not trying to make out that Generics have no place in Computer Science. I was trying to make the case for it being nice that there was a language that didn't have it, and was building on the grandparent saying that he didn't miss it that often, which mirrors my experience with Go.
    - philosopher1234 6y ago
      This is a silly strawman. Developers often write hard to read code, and even if generics are useful to the writer, doesn't mean they are useful to the reader. Many developers do not consider the reader, or if they do, not very in-depth. You can also make the argument that generic code is uniformly harder to read than specific code.
      - wtetzner 6y ago
        I would argue that code using generics is often easier to read than code without it. The fact that something is a type variable makes it clear the that type of that thing doesn't matter.
    - flippinburgers 6y ago
      (c) Some people using generics don't know what they are doing and would be much better off not doing so.
  - jrockway 6y ago
    That ship already sailed with widespread misuse of interfaces. Consider: package foo type T interface { func Bar() } func New() T { return &someotherpackage.ImplPickedAtRuntime{...} } Now whenever you see: x := foo.New() x.Bar() You have no idea where to read the code for Bar. For maximum fun, ImplPickedAtRuntime should then contain members that were allocated in the same way. What should be a simple M-. then eats up your entire afternoon.
thomascgalvin 6y ago
Generics aren't magic, and they aren't Turing complete, like C++ templates. They're just a way to avoid copy-pasting code. Having `Set<Foo>` and `Set<Bar>` is far more readable than `class FooSet` and `class BarSet`, where the code is exactly the same aside from a search-and-replace. You also run into issues where someone finds a bug in `FooSet`, but doesn't know `BarSet` exists, and forgets to patch both. Now, you have two divergent copy-paste classes. Generics solve a bunch of real-world problems, in a very simple manner.
- lkramer 6y ago
  Can you give a real world example that couldn't be solved with interfaces? The only real cases I can see is creating new data structures, (for instance if you wanted to create your own map type).
  - candiddevmike 6y ago
    I think you're looking at it wrong. You can absolutely solve it with interfaces, the problem is those interface methods are identical, so it's duplicative.
    - masklinn 6y ago
      > I think you're looking at it wrong. You can absolutely solve it with interfaces There are lots of generics use case you either can't solve at all with interfaces, or you have to contort every which way and usually lose something in the process (type-safety, performances, readability, …).
  - chowells 6y ago
    You can't use interfaces to prevent inserting values of the wrong types into a set. When you view the purpose of types as preventing bugs, that seems like a giant missing feature.
  - coldtea 6y ago
    >The only real cases I can see is creating new data structures Half of programming is creating new data structures. The other half is tranformations (e.g. map, filter, reduce, min, max, etc) which also benefit from being generic.

deskamess 6y ago

The introduction of generics would not change your workflow though. You could still happily "not use it" and keep matters readable. Others who wanted it, would use it.

lkramer 6y ago
Mostly concerned about having to read other people's code that uses it.
- coldtea 6y ago
  If others people code uses it, then those other people deemed it useful. So the argument for not having them now becames either: (a) they rather not have it available, because you personally don't find it useful (b) those using generic don't know what they're doing, and only people not using generic are smart, so it's better to not have them to prevent the clueless from being able to use them
  - lkramer 6y ago
    Like I said, I use (and like) several languages that have Generics, and when I need to do something where it makes sense, I can reach for those. For me there was an advantage in having a language where it wasn't an option. Your (b) scenario is quite a strawman. I have seen plenty of good code using Generics, but sure, there is subset of code written using Generics that is not good, and I think it becomes easier to obfuscate code and make it hard to read if you have Generics, that might just by my bias, and I think I'm tainted from C++ and hopefully it will never become as bad as what you can encounter there. I'm not trying to make out that Generics have no place in Computer Science. I was trying to make the case for it being nice that there was a language that didn't have it, and was building on the grandparent saying that he didn't miss it that often, which mirrors my experience with Go.
  - philosopher1234 6y ago
    This is a silly strawman. Developers often write hard to read code, and even if generics are useful to the writer, doesn't mean they are useful to the reader. Many developers do not consider the reader, or if they do, not very in-depth. You can also make the argument that generic code is uniformly harder to read than specific code.
    - wtetzner 6y ago
      I would argue that code using generics is often easier to read than code without it. The fact that something is a type variable makes it clear the that type of that thing doesn't matter.
  - flippinburgers 6y ago
    (c) Some people using generics don't know what they are doing and would be much better off not doing so.
- jrockway 6y ago
  That ship already sailed with widespread misuse of interfaces. Consider: package foo type T interface { func Bar() } func New() T { return &someotherpackage.ImplPickedAtRuntime{...} } Now whenever you see: x := foo.New() x.Bar() You have no idea where to read the code for Bar. For maximum fun, ImplPickedAtRuntime should then contain members that were allocated in the same way. What should be a simple M-. then eats up your entire afternoon.

thomascgalvin 6y ago

Generics aren't magic, and they aren't Turing complete, like C++ templates. They're just a way to avoid copy-pasting code. Having `Set<Foo>` and `Set<Bar>` is far more readable than `class FooSet` and `class BarSet`, where the code is exactly the same aside from a search-and-replace. You also run into issues where someone finds a bug in `FooSet`, but doesn't know `BarSet` exists, and forgets to patch both. Now, you have two divergent copy-paste classes. Generics solve a bunch of real-world problems, in a very simple manner.

lkramer 6y ago
Can you give a real world example that couldn't be solved with interfaces? The only real cases I can see is creating new data structures, (for instance if you wanted to create your own map type).
- candiddevmike 6y ago
  I think you're looking at it wrong. You can absolutely solve it with interfaces, the problem is those interface methods are identical, so it's duplicative.
  - masklinn 6y ago
    > I think you're looking at it wrong. You can absolutely solve it with interfaces There are lots of generics use case you either can't solve at all with interfaces, or you have to contort every which way and usually lose something in the process (type-safety, performances, readability, …).
- chowells 6y ago
  You can't use interfaces to prevent inserting values of the wrong types into a set. When you view the purpose of types as preventing bugs, that seems like a giant missing feature.
- coldtea 6y ago
  >The only real cases I can see is creating new data structures Half of programming is creating new data structures. The other half is tranformations (e.g. map, filter, reduce, min, max, etc) which also benefit from being generic.