4 ms·

Is the only argument that Go users can come up with against generics is that they don't like the syntax? The pretentious nature of the Go community really puts

Is the only argument that Go users can come up with against generics is that they don't like the syntax? The pretentious nature of the Go community really puts me off from the language, especially when combined with some of the pretentious designs of Go itself.

marcus_holmes 13y ago
Is the only argument that Go users can come up with against generics is that they don't like the syntax? Surely that's the best argument?
- username223 13y ago
  > Surely that's the best argument? As pathetic as it is, "syntax bad" is probably the best argument.
skybrian 13y ago
No, the argument is that it's unclear how to fit it into the language. Typically, generics are implemented using either code generation (causing code bloat) or type erasure (which requires boxing the type). They're not satisfied with either.
- Sir_Cmpwn 13y ago
  A more accurate version of my comment would refer to "Go users" commenting in this thread.
- smegel 13y ago
  Doesn't Go already do runtime code generation to implement closures?
  - BarkMore 13y ago
    Go does not generate code at runtime.
  - hueho 13y ago
    They changed how closures are implemented in Go 1.1 There is a comprehensive doc by Russ Cox that explains in detail: https://docs.google.com/document/d/1bMwCey-gmqZVTpRax-ESeVuZGmjwbocYs1iHplK-cjo/pub https://docs.google.com/document/d/1bMwCey-gmqZVTpRax-ESeVuZ...
- kristianp 13y ago
  They probably wouldn't be happy with any impact on compile times either.
- groovy2shoes 13y ago
  The "code generation = code bloat" argument really fails when you consider that the code generated for a generic function is code that would be written by hand in the absence of generics. Compare: map f [1, 2, 3] map g [1.0, 2.0, 3.0] Versus: integer_map f [1, 2, 3] double_map g [1.0, 2.0, 3.0] In both cases, you wind up with specialized versions of map (one for Integers and one for Doubles). The benefit of the generic version is that the programmer must only implement map once, and the compiler handles specializing it for various types. Without generics, the programmer has to write the specialized version for every type he needs the function for. This creates more tedium for the programmer, and does not reduce bloat in any way. Caveat lector: Though my examples above are written in Haskell, I don't have enough knowledge of GHC internals to know whether it performs specialization this way. Nonetheless, it could be a reasonable approach for Go.
  - burntsushi 13y ago
    It seems like you disagree with Russ Cox.[1] Unfortunately, I'm not familiar enough with compilers to reconcile the disagreement. Any thoughts? [1] - http://research.swtch.com/generic http://research.swtch.com/generic
    - groovy2shoes 13y ago
      In this regard, C++ templates suffer from two problems. First, C++ templates are far more general than just generic types (in fact, they're Turing complete). Second, and the cause of lots of redundancy, is that C++ has no module system. C++ has no module system, and instead relies on the linker to provide functionality that could reasonably be provided at compile time given a sufficient module system. I'd say that generics in Go could avoid both of these problems: first by being just generics, and second by leveraging the module system. Yes, generics will increase compile times. I seriously doubt it will increase compile times by an integer multiple, and most people probably won't even notice. I'm not entirely sure what's going on that is causing the instruction cache to be underutilized, but it seems to me that the only way to avoid it is to also avoid abstraction in general. As usual, there's a tradeoff between performance and maintainability -- that's nothing new. Pick the appropriate abstractions for your use case. Russ Cox is wrong in this case because his sample consists of one language: C++. Go is not C++, so it's a mistake to assume it will suffer from the same problems. To get an idea of how generics could be reasonably implemented, take the Clay programming language as an example: http://claylabs.com/clay/ http://claylabs.com/clay/
jksmith 13y ago
Interesting word to apply to anything related to golang. Seems more accurate to suggest that golang (and interest) is an alternative to pretentiousness.
vectorpush 13y ago
The pretentious nature of the Go community really puts me off from the language I have had the exact opposite experience with the Go community. In particular, I've found community hubs like #go-nuts and the mailing list to be professional at worst and friendly at best, and always helpful. some of the pretentious designs of Go itself. How can a design be pretentious? Either you favor the design or you don't, but calling it pretentious is simply projecting your own emotions onto the language.
- Sir_Cmpwn 13y ago
  They may not appear that way if you mesh well with the core ideas of Go. I once mentioned that Go does not fit into my usual project setup - I keep git repos in ~/sources. Go requires me to instead dedicate an entire directory structure to my entire Go workspace, which I have to keep seperate from the other sources. This could easily be avoided by letting me set enviornment variables that would relocate some of these folders (especially bin and pkg) to different places. This is an example of how Go as a language is pretentious. It's way is the best way, even when no one else does it that way. The community becomes pretentious whenever you draw criticism against these core choices (note this mostly comes from #go-nuts, I haven't spent a lot of time on the mailing list). I like to believe that I can engage in well-reasoned discourse about these things, and I don't think I have seen the same degree of defensiveness and close-mindedness you might see from most other communities.
  - MetaCosm 13y ago
    It is opinionated (a more useful word than pretentious), and it is this way across many things. From style to directory structure to versioning of dependencies to generics. If you actually read the reasoning behind them, I think they are rather well defended by very smart people, but to each their own. If you really have an issue with some of the very opinionated ideas that come to a large degree bundled with Go, that is fair. That is great even! It probably isn't a good fit for you. Which is fine, there are hundreds of other programming languages that work for you, most are the wild west. For certain people (like myself) the sanity of Go is striking -- each decision is made for unremarkable and straightforward defensible reasons... a lot of them are community driven over personal preference... it is better for the herd (think: herd immunity) if everyone uses one style and everyone uses one layout... etc. It isn't about being "right" or "needed" by every person, it is about being consistent so you can move from project to project and focus on learning the code, not layout or style, just what the code does. Go was designed from inside Google, with large teams in mind with many projects.

marcus_holmes 13y ago

Is the only argument that Go users can come up with against generics is that they don't like the syntax? Surely that's the best argument?

username223 13y ago
> Surely that's the best argument? As pathetic as it is, "syntax bad" is probably the best argument.

skybrian 13y ago

No, the argument is that it's unclear how to fit it into the language. Typically, generics are implemented using either code generation (causing code bloat) or type erasure (which requires boxing the type). They're not satisfied with either.

Sir_Cmpwn 13y ago
A more accurate version of my comment would refer to "Go users" commenting in this thread.
smegel 13y ago
Doesn't Go already do runtime code generation to implement closures?
- BarkMore 13y ago
  Go does not generate code at runtime.
- hueho 13y ago
  They changed how closures are implemented in Go 1.1 There is a comprehensive doc by Russ Cox that explains in detail: https://docs.google.com/document/d/1bMwCey-gmqZVTpRax-ESeVuZGmjwbocYs1iHplK-cjo/pub https://docs.google.com/document/d/1bMwCey-gmqZVTpRax-ESeVuZ...
kristianp 13y ago
They probably wouldn't be happy with any impact on compile times either.
groovy2shoes 13y ago
The "code generation = code bloat" argument really fails when you consider that the code generated for a generic function is code that would be written by hand in the absence of generics. Compare: map f [1, 2, 3] map g [1.0, 2.0, 3.0] Versus: integer_map f [1, 2, 3] double_map g [1.0, 2.0, 3.0] In both cases, you wind up with specialized versions of map (one for Integers and one for Doubles). The benefit of the generic version is that the programmer must only implement map once, and the compiler handles specializing it for various types. Without generics, the programmer has to write the specialized version for every type he needs the function for. This creates more tedium for the programmer, and does not reduce bloat in any way. Caveat lector: Though my examples above are written in Haskell, I don't have enough knowledge of GHC internals to know whether it performs specialization this way. Nonetheless, it could be a reasonable approach for Go.
- burntsushi 13y ago
  It seems like you disagree with Russ Cox.[1] Unfortunately, I'm not familiar enough with compilers to reconcile the disagreement. Any thoughts? [1] - http://research.swtch.com/generic http://research.swtch.com/generic
  - groovy2shoes 13y ago
    In this regard, C++ templates suffer from two problems. First, C++ templates are far more general than just generic types (in fact, they're Turing complete). Second, and the cause of lots of redundancy, is that C++ has no module system. C++ has no module system, and instead relies on the linker to provide functionality that could reasonably be provided at compile time given a sufficient module system. I'd say that generics in Go could avoid both of these problems: first by being just generics, and second by leveraging the module system. Yes, generics will increase compile times. I seriously doubt it will increase compile times by an integer multiple, and most people probably won't even notice. I'm not entirely sure what's going on that is causing the instruction cache to be underutilized, but it seems to me that the only way to avoid it is to also avoid abstraction in general. As usual, there's a tradeoff between performance and maintainability -- that's nothing new. Pick the appropriate abstractions for your use case. Russ Cox is wrong in this case because his sample consists of one language: C++. Go is not C++, so it's a mistake to assume it will suffer from the same problems. To get an idea of how generics could be reasonably implemented, take the Clay programming language as an example: http://claylabs.com/clay/ http://claylabs.com/clay/

jksmith 13y ago

Interesting word to apply to anything related to golang. Seems more accurate to suggest that golang (and interest) is an alternative to pretentiousness.

vectorpush 13y ago

The pretentious nature of the Go community really puts me off from the language I have had the exact opposite experience with the Go community. In particular, I've found community hubs like #go-nuts and the mailing list to be professional at worst and friendly at best, and always helpful. some of the pretentious designs of Go itself. How can a design be pretentious? Either you favor the design or you don't, but calling it pretentious is simply projecting your own emotions onto the language.

Sir_Cmpwn 13y ago
They may not appear that way if you mesh well with the core ideas of Go. I once mentioned that Go does not fit into my usual project setup - I keep git repos in ~/sources. Go requires me to instead dedicate an entire directory structure to my entire Go workspace, which I have to keep seperate from the other sources. This could easily be avoided by letting me set enviornment variables that would relocate some of these folders (especially bin and pkg) to different places. This is an example of how Go as a language is pretentious. It's way is the best way, even when no one else does it that way. The community becomes pretentious whenever you draw criticism against these core choices (note this mostly comes from #go-nuts, I haven't spent a lot of time on the mailing list). I like to believe that I can engage in well-reasoned discourse about these things, and I don't think I have seen the same degree of defensiveness and close-mindedness you might see from most other communities.
- MetaCosm 13y ago
  It is opinionated (a more useful word than pretentious), and it is this way across many things. From style to directory structure to versioning of dependencies to generics. If you actually read the reasoning behind them, I think they are rather well defended by very smart people, but to each their own. If you really have an issue with some of the very opinionated ideas that come to a large degree bundled with Go, that is fair. That is great even! It probably isn't a good fit for you. Which is fine, there are hundreds of other programming languages that work for you, most are the wild west. For certain people (like myself) the sanity of Go is striking -- each decision is made for unremarkable and straightforward defensible reasons... a lot of them are community driven over personal preference... it is better for the herd (think: herd immunity) if everyone uses one style and everyone uses one layout... etc. It isn't about being "right" or "needed" by every person, it is about being consistent so you can move from project to project and focus on learning the code, not layout or style, just what the code does. Go was designed from inside Google, with large teams in mind with many projects.