5 ms·

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

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.
- pjmlp 11y ago
  To add to your list C++ guys are still waiting for modules.
- artursapek 11y ago
  It's funny that you mention Java because I have always avoided learning Java. Even from afar it grosses me out as a language. I actually think comparing Go to Java is silly because a lot of motivation behind Go's design came out of avoiding what was done to Java and C++. The point is, plenty of companies manage to create very good production software with Go, without generics. I didn't mean to rest my argument on my personal anecdote. You can look to Google, CloudFlare, SoundCloud, Dropbox, etc. for reassurance. If you have a suggestion on how generics would fit into Go, I think the Go team would be happy to read your thoughts: https://groups.google.com/forum/#!forum/golang-nuts https://groups.google.com/forum/#!forum/golang-nuts.
  - coldtea 11y ago
    >It's funny that you mention Java because I have always avoided learning Java. Even from afar it grosses me out as a language. May I guess you're either some old Lisp/Smalltalk etc veteran, or, much more probably, someone who entered IT after, say 2005? Because back in the day very few thought of Java as "gross" -- it was greeted as a welcome change from the existing landscape which at its best was something like C++.
    - artursapek 11y ago
      I'm 23, I haven't been around that long :)
      - coldtea 11y ago
        Yeah, so the second case, someone who entered IT after 2005! I guessed so, because back in the day (1995-early 00's) most devs outside of seasoned functional etc veterans (who were extremely few) or hardcore systems guys, saw Java in mostly positive light, and never considered it "boring" back then. The change (for new devs to consider Java "boring" and lacking in features) happened sometime after 2005, with Rails entering, Javascript catching up, C# getting more features with 2.0 and 3.0. (Consider than back then Scala, Go, Clojure et al weren't even started, and AJAX had just been made mainstream).
threeseed 11y ago
The tired old argument gets trotted out again. If an important, beneficial addition to the language is missing then it's by design and if you don't like it go use something else.

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.

pjmlp 11y ago
To add to your list C++ guys are still waiting for modules.
artursapek 11y ago
It's funny that you mention Java because I have always avoided learning Java. Even from afar it grosses me out as a language. I actually think comparing Go to Java is silly because a lot of motivation behind Go's design came out of avoiding what was done to Java and C++. The point is, plenty of companies manage to create very good production software with Go, without generics. I didn't mean to rest my argument on my personal anecdote. You can look to Google, CloudFlare, SoundCloud, Dropbox, etc. for reassurance. If you have a suggestion on how generics would fit into Go, I think the Go team would be happy to read your thoughts: https://groups.google.com/forum/#!forum/golang-nuts https://groups.google.com/forum/#!forum/golang-nuts.
- coldtea 11y ago
  >It's funny that you mention Java because I have always avoided learning Java. Even from afar it grosses me out as a language. May I guess you're either some old Lisp/Smalltalk etc veteran, or, much more probably, someone who entered IT after, say 2005? Because back in the day very few thought of Java as "gross" -- it was greeted as a welcome change from the existing landscape which at its best was something like C++.
  - artursapek 11y ago
    I'm 23, I haven't been around that long :)
    - coldtea 11y ago
      Yeah, so the second case, someone who entered IT after 2005! I guessed so, because back in the day (1995-early 00's) most devs outside of seasoned functional etc veterans (who were extremely few) or hardcore systems guys, saw Java in mostly positive light, and never considered it "boring" back then. The change (for new devs to consider Java "boring" and lacking in features) happened sometime after 2005, with Rails entering, Javascript catching up, C# getting more features with 2.0 and 3.0. (Consider than back then Scala, Go, Clojure et al weren't even started, and AJAX had just been made mainstream).

threeseed 11y ago

The tired old argument gets trotted out again. If an important, beneficial addition to the language is missing then it's by design and if you don't like it go use something else.