5 ms·

I would participate in an argument only for a language that I am invested in. When it comes to go, most people who argue about generics, do not write go and pro

I would participate in an argument only for a language that I am invested in. When it comes to go, most people who argue about generics, do not write go and probably wouldn't touch it even if it had generics. Also, an important issue with such arguments, is that generics is a feature, so obviously it is an easy side to choose for an argument. You can either have or don't have a feature. People will instinctively select the have option because common sense dictates that it is better to have something even if you don't use it. People want to quantify an argument and having is better than not having. People don't want to argue about language design —there are few people on the planet that could really argue about language design anyway-, they need language MHz to compare.

coldtea 9y ago
>I would participate in an argument only for a language that I am invested in. When it comes to go, most people who argue about generics, do not write go and probably wouldn't touch it even if it had generics. Citation needed. >Also, an important issue with such arguments, is that generics is a feature, so obviously it is an easy side to choose for an argument. You can either have or don't have a feature. People will instinctively select the have option because common sense dictates that it is better to have something even if you don't use it. People want to quantify an argument and having is better than not having. This non-argument could be applied against adding ANY feature at all. The idea that there are more enlightened users who care about "language design" and the unwashed masses who want to add everything and the kitchen sink to Golang and spoil it does not hold water (Besides, even if it was true, people who care about language design do not particularly see 90% of Algol 68 + CSP as anything to write home about). People dont ask for all kinds of BS to be added to Go -- the ask for certain things that are actual pain points. And the list the 2016 Survey post gives is quite sensible (Generics, better error handling, better packaging, etc) and specifically applicable to Golang pain points.
tragic 9y ago
> When it comes to go, most people who argue about generics, do not write go and probably wouldn't touch it even if it had generics. Although I have no more proof of the contrary position than you have for this assertion, I must still insist that it is bizarre. Generic types are not some bleeding edge piece of CS research, of interest only to academics. We have already fought this war in Java, for heaven's sake. Even despite the problems with Java generics, I don't think many people would want to go back. There is of course a complexity cost, but there is also a cost of not implementing generics, that code is more brittle and more reliable on casts and runtime assertions. Is this really so awesome?
danaliv 9y ago
> 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.

coldtea 9y ago

>I would participate in an argument only for a language that I am invested in. When it comes to go, most people who argue about generics, do not write go and probably wouldn't touch it even if it had generics. Citation needed. >Also, an important issue with such arguments, is that generics is a feature, so obviously it is an easy side to choose for an argument. You can either have or don't have a feature. People will instinctively select the have option because common sense dictates that it is better to have something even if you don't use it. People want to quantify an argument and having is better than not having. This non-argument could be applied against adding ANY feature at all. The idea that there are more enlightened users who care about "language design" and the unwashed masses who want to add everything and the kitchen sink to Golang and spoil it does not hold water (Besides, even if it was true, people who care about language design do not particularly see 90% of Algol 68 + CSP as anything to write home about). People dont ask for all kinds of BS to be added to Go -- the ask for certain things that are actual pain points. And the list the 2016 Survey post gives is quite sensible (Generics, better error handling, better packaging, etc) and specifically applicable to Golang pain points.

tragic 9y ago

> When it comes to go, most people who argue about generics, do not write go and probably wouldn't touch it even if it had generics. Although I have no more proof of the contrary position than you have for this assertion, I must still insist that it is bizarre. Generic types are not some bleeding edge piece of CS research, of interest only to academics. We have already fought this war in Java, for heaven's sake. Even despite the problems with Java generics, I don't think many people would want to go back. There is of course a complexity cost, but there is also a cost of not implementing generics, that code is more brittle and more reliable on casts and runtime assertions. Is this really so awesome?

danaliv 9y ago

> 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.