4 ms·

>People have been asking for generics as a standalone feature first and foremost -- orthogonal from replacing error handling. There are many languages out ther

>People have been asking for generics as a standalone feature first and foremost -- orthogonal from replacing error handling. There are many languages out there that have generics. Go is build on different principals. Just use something else, no need to enforce your ideas on people who don't want them. Maybe go users should start going into every language discussion they can find and ask for generics to be removed.

pcwalton 9y ago
If you can successfully argue that generics should be removed from other languages, then you should feel free to argue that. The reason why nobody is arguing that is that it's hard to argue successfully, because simple ML-style generics are incredibly useful and have negligible if any drawbacks in virtually every statically typed language.
- andmarios 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. 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.
the_duke 9y ago
I remember reading a comment from one of the go developers that the lack of generics is not some big design decision, it just didn't make it into 1. The more defining features are goroutines and the type system. (Structs, embedding, interfaces, ...). Go has multiple built in generics anyway. (Slices, maps, channels), so it's not like it could be some big principle to not have them. Generics would take away the ridiculous amounts of boilerplate that go requires, and make the language much, much nicer to use. And safer too. The amount of `interface{}` in a lot of go code is such a smell.. always makes me wonder what the point of using a statically typed language is if you use interface{} and type casting all the time.
coldtea 9y ago
There are several misconceptions here. First, Go wasn't designed with "avoid Generics" as some kind of principle. That was the quick 1.0 version, but even before 1.0 it's creators have discussed (and usually post-pone to some future) the addition of generics. Russ Cox: " I don’t believe the Go team has ever said 'Go does not need generics.' What we have said is that there are higher-priority issues facing Go." Second, it's not some "non Go users" who ask for Generics in Go. Rather the opposite: non Go users could not care less. They have their generic C++, Rust, D, Nim, C#, Java or whatever. Generics are among the most asked features from actual Go users. Sure, there are old school Go users (and most of the Golang core team) who think they're just OK without it, or not worth the trouble. But a large majority of the Go community does ask for them. I didn't pull this out of my arse (besides it being obvious if you read Go blogs and forums). Here from the official 2016 Survey Results: "When asked what changes would most improve Go, users most commonly mentioned _generics_, package versioning, and dependency management. Other popular responses were GUIs, debugging, and error handling." (emphasis mine).

pcwalton 9y ago

If you can successfully argue that generics should be removed from other languages, then you should feel free to argue that. The reason why nobody is arguing that is that it's hard to argue successfully, because simple ML-style generics are incredibly useful and have negligible if any drawbacks in virtually every statically typed language.

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

the_duke 9y ago

I remember reading a comment from one of the go developers that the lack of generics is not some big design decision, it just didn't make it into 1. The more defining features are goroutines and the type system. (Structs, embedding, interfaces, ...). Go has multiple built in generics anyway. (Slices, maps, channels), so it's not like it could be some big principle to not have them. Generics would take away the ridiculous amounts of boilerplate that go requires, and make the language much, much nicer to use. And safer too. The amount of `interface{}` in a lot of go code is such a smell.. always makes me wonder what the point of using a statically typed language is if you use interface{} and type casting all the time.

coldtea 9y ago

There are several misconceptions here. First, Go wasn't designed with "avoid Generics" as some kind of principle. That was the quick 1.0 version, but even before 1.0 it's creators have discussed (and usually post-pone to some future) the addition of generics. Russ Cox: " I don’t believe the Go team has ever said 'Go does not need generics.' What we have said is that there are higher-priority issues facing Go." Second, it's not some "non Go users" who ask for Generics in Go. Rather the opposite: non Go users could not care less. They have their generic C++, Rust, D, Nim, C#, Java or whatever. Generics are among the most asked features from actual Go users. Sure, there are old school Go users (and most of the Golang core team) who think they're just OK without it, or not worth the trouble. But a large majority of the Go community does ask for them. I didn't pull this out of my arse (besides it being obvious if you read Go blogs and forums). Here from the official 2016 Survey Results: "When asked what changes would most improve Go, users most commonly mentioned _generics_, package versioning, and dependency management. Other popular responses were GUIs, debugging, and error handling." (emphasis mine).