6 ms·

It is fairly clear by now that omitting generics is not an oversight, but rather a design choice. If you disagree, it sounds like Go isn't for you. Maybe it'

by ohto 11y ago

It is fairly clear by now that omitting generics is not an oversight, but rather a design choice. If you disagree, it sounds like Go isn't for you. Maybe it's time to just move on and ignore it instead of beating a dead horse. I am always confused by the push to make every language exactly the same by using the same paradigms and features. Some languages try to take a different approach. If you can't figure out how to work within that paradigm, don't use it. Your comment is akin to complaining that Haskell doesn't support an imperative style.

DanWaterworth 11y ago
The Go faq doesn't agree with you.
- sambeau 11y ago
  You are both correct. It is by design that Go does not have generics as the Go team have not found a design they feel works and they are unwilling to compromise the current design. They may never.
- blowski 11y ago
  You're both right. I'm paraphrasing, but the FAQ says "We will add generics if somebody can demonstrate that the value of doing so would outweigh the complexity it would add". I'm assuming nobody has demonstrated that, so they haven't added them.
  - meddlepal 11y ago
    Should really read "We will add generics if somebody can perform the impossible and convince the very stubborn and opinionated Go leadership that the value of doing would outweigh the complexity it would add".
- ohto 11y ago
  Nonsense. Reread the FAQ. They are choosing to not implement generics. If someone can find a way to implement them without violating Go's design principles, they will. In other words, it's a choice. It's not that they just haven't got around to it.
tome 11y ago
> not an oversight, but rather a design choice Why not both?
- michaelcampbell 11y ago
  You can choose an oversight? Once chosen, it ceases to be, no?
  - tome 11y ago
    I suppose it depends on the precise definition of "oversight". My understanding of the term allows it to be used when someone deliberately chooses a course of action, but not having taken into account the full consequences.
    - pessimizer 11y ago
      > I suppose it depends on the precise definition of "oversight". Good luck; it's an autoantonym. In my experience, your usage is as common as many others, though.
coldtea 11y ago
>I am always confused by the push to make every language exactly the same by using the same paradigms and features. More like: some paradigms and features have been proved useful, and experienced programmers ask for them in a language that lacks them. And not indiscriminately, but usually only ask for them if that language is of a certain paradigm / family of languages were those things fit well with (e.g. few ask for immutability in Go, or logical programming in Javascript). >Some languages try to take a different approach. Yes, the wrong one. >If you can't figure out how to work within that paradigm, don't use it. A lack of a feature is not always a "paradigm". Besides, by the same logic, every language is perfect as is all the time, and users and potential adopters should not ask for anything new. The lack of closures in Java for ages is a strong counter-argument to that. Or the rejoicing by which people adopted "auto" in C++. And tons of other examples, besides... >Your comment is akin to complaining that Haskell doesn't support an imperative style. More like his comment is akin to complaining that Java doesn't have Generics (pre 1.5).
- artursapek 11y ago
  Please just stop. This is not an objective issue. I for one have spent the last 2 years using Go to build a very performant system which is used by thousands of Bitcoin day traders every day. It's fast, stable, and easy to modify. I have never felt held back by a lack of generics. And yes, I've spent plenty of time using languages that do support generics. It can save you time but I've found it also enables "looser" code, which can be more error-prone. In fact one of my favorite things about Go is how restrictive its type system is. I feel a lot more confident about my code doing only what I think it's doing when using Go. If they find a way to introduce generics while upholding Go's other strong points (fast compilation being another), then great. But it looks like it's not trivial. If the language is not for you, move on. There are plenty of us who are perfectly happy to write code without generics. Your condescending remarks are entirely unproductive.
  - coldtea 11y ago
    >Please just stop. This is not an objective issue. When it comes to computer science generics have been an accepted part of PL research for decades. The extra expression power they give and the paradigms they enable are neither controversial, not something that's up to individual tastes to judge. Someone might not like them subjectively, but that's not different than someone not liking closures, or map or any other established thing. People will always have their preferences. >I for one have spent the last 2 years using Go to build a very performant system which is used by thousands of Bitcoin day traders every day. It's fast, stable, and easy to modify. I have never felt held back by a lack of generics. That doesn't prove it's not an objective issue, just that a specific use case, in a specific domain, didn't need it. Or even more precisely, that a specific programmer didn't feel the need "held back" by their lack. Perhaps others would feel "pushed forward" by their presence. For example, I mentioned Java above, who only got Generics after 10 years. Tons of far bigger Java programs than the one described have been created with Java-without-Generics (from financial services to automobile controllers). All those projects weren't any "proof" that Java doesn't need Generics (and/or closures). Just that you can do without them too (which is true -- nobody argues that you can't). Besides, isn't Paul Grahams whole "Blub" concept based on the idea that people using languages without X features have little means to understand their importance (and what they're missing)? In any case, there are counter-examples to what you write too: several posts from teams that have used Go in production that say they like it but still lament the lack of generics. >And yes, I've spent plenty of time using languages that do support generics. It can save you time but I've found it also enables "looser" code, which can be more error-prone. In fact one of my favorite things about Go is how restrictive its type system is. I feel a lot more confident about my code doing only what I think it's doing when using Go. Generics are not "loose", if anything they're even tighter type-wise than what Go makes you do to overcome their absence. Either you create concrete types for everything, ad nauseum, or you go "loose" and use interface{} and the like, throwing a lot of assurances out of the window. >If the language is not for you, move on. There are plenty of us who are perfectly happy to write code without generics. Again, happiness doesn't say much -- that's personal preference and can't be debated. Java programmers were perfectly happy to write code without Generics and Closures for like 15 years too. Most were even oblivious that those things existed in the PL world at large. Javascript programmers suffered without correct scoping or an import system for 20 years, etc.
Peaker 11y ago
Haskell does support an imperative style, supports it quite well even :)

by ohto 11y ago

DanWaterworth 11y ago

The Go faq doesn't agree with you.

sambeau 11y ago
You are both correct. It is by design that Go does not have generics as the Go team have not found a design they feel works and they are unwilling to compromise the current design. They may never.
blowski 11y ago
You're both right. I'm paraphrasing, but the FAQ says "We will add generics if somebody can demonstrate that the value of doing so would outweigh the complexity it would add". I'm assuming nobody has demonstrated that, so they haven't added them.
- meddlepal 11y ago
  Should really read "We will add generics if somebody can perform the impossible and convince the very stubborn and opinionated Go leadership that the value of doing would outweigh the complexity it would add".
ohto 11y ago
Nonsense. Reread the FAQ. They are choosing to not implement generics. If someone can find a way to implement them without violating Go's design principles, they will. In other words, it's a choice. It's not that they just haven't got around to it.

tome 11y ago

> not an oversight, but rather a design choice Why not both?

michaelcampbell 11y ago
You can choose an oversight? Once chosen, it ceases to be, no?
- tome 11y ago
  I suppose it depends on the precise definition of "oversight". My understanding of the term allows it to be used when someone deliberately chooses a course of action, but not having taken into account the full consequences.
  - pessimizer 11y ago
    > I suppose it depends on the precise definition of "oversight". Good luck; it's an autoantonym. In my experience, your usage is as common as many others, though.

coldtea 11y ago

>I am always confused by the push to make every language exactly the same by using the same paradigms and features. More like: some paradigms and features have been proved useful, and experienced programmers ask for them in a language that lacks them. And not indiscriminately, but usually only ask for them if that language is of a certain paradigm / family of languages were those things fit well with (e.g. few ask for immutability in Go, or logical programming in Javascript). >Some languages try to take a different approach. Yes, the wrong one. >If you can't figure out how to work within that paradigm, don't use it. A lack of a feature is not always a "paradigm". Besides, by the same logic, every language is perfect as is all the time, and users and potential adopters should not ask for anything new. The lack of closures in Java for ages is a strong counter-argument to that. Or the rejoicing by which people adopted "auto" in C++. And tons of other examples, besides... >Your comment is akin to complaining that Haskell doesn't support an imperative style. More like his comment is akin to complaining that Java doesn't have Generics (pre 1.5).

artursapek 11y ago
Please just stop. This is not an objective issue. I for one have spent the last 2 years using Go to build a very performant system which is used by thousands of Bitcoin day traders every day. It's fast, stable, and easy to modify. I have never felt held back by a lack of generics. And yes, I've spent plenty of time using languages that do support generics. It can save you time but I've found it also enables "looser" code, which can be more error-prone. In fact one of my favorite things about Go is how restrictive its type system is. I feel a lot more confident about my code doing only what I think it's doing when using Go. If they find a way to introduce generics while upholding Go's other strong points (fast compilation being another), then great. But it looks like it's not trivial. If the language is not for you, move on. There are plenty of us who are perfectly happy to write code without generics. Your condescending remarks are entirely unproductive.
- coldtea 11y ago
  >Please just stop. This is not an objective issue. When it comes to computer science generics have been an accepted part of PL research for decades. The extra expression power they give and the paradigms they enable are neither controversial, not something that's up to individual tastes to judge. Someone might not like them subjectively, but that's not different than someone not liking closures, or map or any other established thing. People will always have their preferences. >I for one have spent the last 2 years using Go to build a very performant system which is used by thousands of Bitcoin day traders every day. It's fast, stable, and easy to modify. I have never felt held back by a lack of generics. That doesn't prove it's not an objective issue, just that a specific use case, in a specific domain, didn't need it. Or even more precisely, that a specific programmer didn't feel the need "held back" by their lack. Perhaps others would feel "pushed forward" by their presence. For example, I mentioned Java above, who only got Generics after 10 years. Tons of far bigger Java programs than the one described have been created with Java-without-Generics (from financial services to automobile controllers). All those projects weren't any "proof" that Java doesn't need Generics (and/or closures). Just that you can do without them too (which is true -- nobody argues that you can't). Besides, isn't Paul Grahams whole "Blub" concept based on the idea that people using languages without X features have little means to understand their importance (and what they're missing)? In any case, there are counter-examples to what you write too: several posts from teams that have used Go in production that say they like it but still lament the lack of generics. >And yes, I've spent plenty of time using languages that do support generics. It can save you time but I've found it also enables "looser" code, which can be more error-prone. In fact one of my favorite things about Go is how restrictive its type system is. I feel a lot more confident about my code doing only what I think it's doing when using Go. Generics are not "loose", if anything they're even tighter type-wise than what Go makes you do to overcome their absence. Either you create concrete types for everything, ad nauseum, or you go "loose" and use interface{} and the like, throwing a lot of assurances out of the window. >If the language is not for you, move on. There are plenty of us who are perfectly happy to write code without generics. Again, happiness doesn't say much -- that's personal preference and can't be debated. Java programmers were perfectly happy to write code without Generics and Closures for like 15 years too. Most were even oblivious that those things existed in the PL world at large. Javascript programmers suffered without correct scoping or an import system for 20 years, etc.

Peaker 11y ago

Haskell does support an imperative style, supports it quite well even :)