3 ms·

> most people who argue about generics, do not write go and probably wouldn't touch it even if it had generics. I wrote Go at work for two years and the lack o

> most people who argue about generics, do not write go and probably wouldn't touch it even if it had generics. I wrote Go at work for two years and the lack of generics made me want to scream on a near-hourly basis.

grey-area 9y ago
Can you give some examples of areas where this lack really annoyed you, given your experience with other languages? Was generics your only problem with Go?
- littlestymaar 9y ago
  Not the gp, but I think my own experience may also be relevant. Since the birth of Go it's been impossible for many years to create something like a thread-safe reusable hashmap[1], which is pretty annoying when all your code is multi-threaded in goroutines. And creating such hashmap was impossible due to the lack of generics. If you wanted to build your own concurrent hashmap, you had basically 3 bad options : - you use `interface{}`, which is bad because of the dynamics dispatch (slow)[2] and it's also not type-safe. - you use code generation, which is bad because I haven't left the JavaScript world to start using babel for Go … - you create a specialized hashmap for every type you need, this basically means copy-pasting the same piece of code ever and ever and changing the type signatures, which is error prone and a hassle to maintain. [1] this is eventually gonna get better in the next release, since a concurrent hashmap will be included in `sync`. [2] an illustration of the performance problem with dynamic dispatch can be found here : https://github.com/nieksand/sortgenerics https://github.com/nieksand/sortgenerics
  - grey-area 9y ago
    I too feel like containers are the main area where it is painful. The sort of built-in generics we have in Go are useful in most circumstances, but it'd be nice to have custom containers which could take any type, instead of having to specify them separately. Errors is the other area where it feels like they could help (though the article points out possible problems with this). That said your third approach (make custom concrete types as required) has not been a huge problem for me in practice, and is probably the best choice for now.

grey-area 9y ago

Can you give some examples of areas where this lack really annoyed you, given your experience with other languages? Was generics your only problem with Go?

littlestymaar 9y ago
Not the gp, but I think my own experience may also be relevant. Since the birth of Go it's been impossible for many years to create something like a thread-safe reusable hashmap[1], which is pretty annoying when all your code is multi-threaded in goroutines. And creating such hashmap was impossible due to the lack of generics. If you wanted to build your own concurrent hashmap, you had basically 3 bad options : - you use `interface{}`, which is bad because of the dynamics dispatch (slow)[2] and it's also not type-safe. - you use code generation, which is bad because I haven't left the JavaScript world to start using babel for Go … - you create a specialized hashmap for every type you need, this basically means copy-pasting the same piece of code ever and ever and changing the type signatures, which is error prone and a hassle to maintain. [1] this is eventually gonna get better in the next release, since a concurrent hashmap will be included in `sync`. [2] an illustration of the performance problem with dynamic dispatch can be found here : https://github.com/nieksand/sortgenerics https://github.com/nieksand/sortgenerics
- grey-area 9y ago
  I too feel like containers are the main area where it is painful. The sort of built-in generics we have in Go are useful in most circumstances, but it'd be nice to have custom containers which could take any type, instead of having to specify them separately. Errors is the other area where it feels like they could help (though the article points out possible problems with this). That said your third approach (make custom concrete types as required) has not been a huge problem for me in practice, and is probably the best choice for now.