6 ms·

When I think of generics i think custom data structures. Currently you are stuck with interfaces, but you can also wrap a library returning interfaces with meth

When I think of generics i think custom data structures. Currently you are stuck with interfaces, but you can also wrap a library returning interfaces with methods operating on a specific type. I would be interested to hear about use cases that couldn't be solved in this manner

tree_of_item 8y ago
"Solved" by having lots of meaningless unsafe glue code. That's not a solution. It sounds like you're going to reject proposals for generics on the grounds that "you could just cast values of type `interface{}`" unless someone can show you a situation where you can't do that. The problem is that the people who want this sort of feature don't think that's even a solution.
- dilatedmind 8y ago
  I am legitimately asking, it's not something I have personally had much issue with. If you have some compelling example, please share your experience
  - lederhosen 8y ago
    You can not have a custom collection class containing objects _only_ of a certain type. For example ConcurrentHashTable<Int, String>. That is something that is used every single day. It is used so frequently that Go has generic slice and map built into the language. That is, they created a language with lots of special datatypes that can not be created in normal Go because of its lack of generics instead of creating generics. It is a bit like asking a Java-programmer to use Java 1.4. When you ask a Java programmer, or C# programmer or Haskell programmer or Swift programmer or... what they would change in the language you do not get the answer: remove generics.
    - nordsieck 8y ago
      > You can not have a custom collection class containing objects _only_ of a certain type. For example ConcurrentHashTable<Int, String>. I'll start by saying - I largely agree with you. Libraries, particularly of data structures, are the biggest weakness of Go as a language. However, this bit is not really fair: > When you ask a Java programmer, or C# programmer or Haskell programmer or Swift programmer or... what they would change in the language you do not get the answer: remove generics. Much like values, language features need to be compared to each other, not evaluated in isolation. Everyone likes loyalty, but some people value it over honesty and some value the reverse. Everyone likes generics, but some people value faster compile times, a more simple language implementation and a lower learning curve more. Some people value it less.
      - lederhosen 8y ago
        If you value compile times (and you actually think generics make a difference, I do not) you would not make slices and hash tables generic like in Go, would you? If you wanted a simpler language, you would not make slices and hash tables generic, would you? If you wanted lower learning curve, you would not make special case generics would you? If you wanted to wait, to get the perfect generic solution because a sub-optimal one is not good enough, you would not create a sub-optimal non-perfect temporal solution with special-cased generics for certain data types would you? If you argue that I am loyal and not honest, and therefore like generics because it is used in my favorite language, I think you are wrong. The languages I use most of the time have a huge design flaw. It is called null. But when they created Go they chose to (except in special cases) get rid of (useful) generics instead of the disaster that is null. The problem is that Go has not learnt from other languages. It is too imperative, not expressive enough, lacking in static typing and horrible at fault handling.
        foldr 8y ago
        >(and you actually think generics make a difference, I do not) It's pretty difficult for generics not to adversely affect compile times. This is especially so if you actually emit specialized code for each type.
    - dilatedmind 8y ago
      Not without either implementing it yourself or wrapping interface methods. Go generate is like a manual step for having generics, I imagine one day soon its functionality or something similar will be part of go build. In response to your particular example, a map plus a mutex seems sufficient. I dig that it's a few extra lines of code, but I guess I'm looking for a really mean example.
      - lederhosen 8y ago
        I can not create a really mean example because Go is Turing complete. That means that everything can (with a few extra lines) be expressed in Go. The problem with your mutex solution is at least two: 1) it is more complex * more lines to type and read and check and thus harder to understand * you can forget the mutex * if you have data structures of hastables, you will have to pass mutexes around or store them together with the tables. 2) it is not nearly as performent as a lock free hash table (edit indentation)
      - coldtea 8y ago
        >I dig that it's a few extra lines of code, but I guess I'm looking for a really mean example. Well, if you don't care about repeating yourself, mistakes by omission, needless boilerplate, and/or loss of type safety, then, sure, everything is possible in "a few extra lines of code" in a turing complete language...
      - pjmlp 8y ago
        Back when Borland C++ 2.0 came out for MS-DOS, templates were still being designed. So the first version of BIDS, Borland's C++ data structures library, used pre-processor tricks where one defined the types before including the respective data structure. So go generate as workaround feels quite old.
    - taeric 8y ago
      Oddly, I have pushed back on many devs introducing generic interfaces. For library writers, they can be nice. For everyone else, they typically just get you in trouble. So, I don't want to remove them from the language. However, I do question a large percentage is their use in everyday programming.
      - lederhosen 8y ago
        Generics are useful all the time. That is why Go has generic Maps and slices. The question is why I am not allowed to use other generic collections.
        taeric 8y ago
        No, generic collections are pretty much useful all of the time. Other generic things are useful when done well.
  - deleted 8y ago
    [deleted]

tree_of_item 8y ago

"Solved" by having lots of meaningless unsafe glue code. That's not a solution. It sounds like you're going to reject proposals for generics on the grounds that "you could just cast values of type `interface{}`" unless someone can show you a situation where you can't do that. The problem is that the people who want this sort of feature don't think that's even a solution.

dilatedmind 8y ago
I am legitimately asking, it's not something I have personally had much issue with. If you have some compelling example, please share your experience
- lederhosen 8y ago
  You can not have a custom collection class containing objects _only_ of a certain type. For example ConcurrentHashTable<Int, String>. That is something that is used every single day. It is used so frequently that Go has generic slice and map built into the language. That is, they created a language with lots of special datatypes that can not be created in normal Go because of its lack of generics instead of creating generics. It is a bit like asking a Java-programmer to use Java 1.4. When you ask a Java programmer, or C# programmer or Haskell programmer or Swift programmer or... what they would change in the language you do not get the answer: remove generics.
  - nordsieck 8y ago
    > You can not have a custom collection class containing objects _only_ of a certain type. For example ConcurrentHashTable<Int, String>. I'll start by saying - I largely agree with you. Libraries, particularly of data structures, are the biggest weakness of Go as a language. However, this bit is not really fair: > When you ask a Java programmer, or C# programmer or Haskell programmer or Swift programmer or... what they would change in the language you do not get the answer: remove generics. Much like values, language features need to be compared to each other, not evaluated in isolation. Everyone likes loyalty, but some people value it over honesty and some value the reverse. Everyone likes generics, but some people value faster compile times, a more simple language implementation and a lower learning curve more. Some people value it less.
    - lederhosen 8y ago
      If you value compile times (and you actually think generics make a difference, I do not) you would not make slices and hash tables generic like in Go, would you? If you wanted a simpler language, you would not make slices and hash tables generic, would you? If you wanted lower learning curve, you would not make special case generics would you? If you wanted to wait, to get the perfect generic solution because a sub-optimal one is not good enough, you would not create a sub-optimal non-perfect temporal solution with special-cased generics for certain data types would you? If you argue that I am loyal and not honest, and therefore like generics because it is used in my favorite language, I think you are wrong. The languages I use most of the time have a huge design flaw. It is called null. But when they created Go they chose to (except in special cases) get rid of (useful) generics instead of the disaster that is null. The problem is that Go has not learnt from other languages. It is too imperative, not expressive enough, lacking in static typing and horrible at fault handling.
      - foldr 8y ago
        >(and you actually think generics make a difference, I do not) It's pretty difficult for generics not to adversely affect compile times. This is especially so if you actually emit specialized code for each type.
  - dilatedmind 8y ago
    Not without either implementing it yourself or wrapping interface methods. Go generate is like a manual step for having generics, I imagine one day soon its functionality or something similar will be part of go build. In response to your particular example, a map plus a mutex seems sufficient. I dig that it's a few extra lines of code, but I guess I'm looking for a really mean example.
    - lederhosen 8y ago
      I can not create a really mean example because Go is Turing complete. That means that everything can (with a few extra lines) be expressed in Go. The problem with your mutex solution is at least two: 1) it is more complex * more lines to type and read and check and thus harder to understand * you can forget the mutex * if you have data structures of hastables, you will have to pass mutexes around or store them together with the tables. 2) it is not nearly as performent as a lock free hash table (edit indentation)
    - coldtea 8y ago
      >I dig that it's a few extra lines of code, but I guess I'm looking for a really mean example. Well, if you don't care about repeating yourself, mistakes by omission, needless boilerplate, and/or loss of type safety, then, sure, everything is possible in "a few extra lines of code" in a turing complete language...
    - pjmlp 8y ago
      Back when Borland C++ 2.0 came out for MS-DOS, templates were still being designed. So the first version of BIDS, Borland's C++ data structures library, used pre-processor tricks where one defined the types before including the respective data structure. So go generate as workaround feels quite old.
  - taeric 8y ago
    Oddly, I have pushed back on many devs introducing generic interfaces. For library writers, they can be nice. For everyone else, they typically just get you in trouble. So, I don't want to remove them from the language. However, I do question a large percentage is their use in everyday programming.
    - lederhosen 8y ago
      Generics are useful all the time. That is why Go has generic Maps and slices. The question is why I am not allowed to use other generic collections.
      - taeric 8y ago
        No, generic collections are pretty much useful all of the time. Other generic things are useful when done well.
- deleted 8y ago
  [deleted]