8 ms·

Yeah, good luck getting generics.

golergka 9y ago
I don't know why you're downvoted. Generics is a feature that's holding back a lot of developers dealing with complicated business logic (and need for abstraction) from moving to Go. And at the same time, including generics into the language means that all libraries will add generics interfaces - and most probably, stop supporting the old, non-generic interfaces in some time into the future, breaking backwards compatibility at some point.
- _ph_ 9y ago
  I am one who downvoted that statement, because I considered it a snippy remark without any content. Especially, as the question of generics in Go has been mentioned and discussed often enough. And if one feels the need to restart that discussion with each Go release, one should do so with an insightful comment. I do not agree with your comment. I don't see how generics are needed to deal with "complex business logic". Yes, ultimately I would like to see generics added to the Go language. As does the Go development team. But, as they have clearly laid out, this is not a trivial undertaking. There hasn't yet been an implementation concept presented, which fits into the Go framework with its design goals. And until then, I am quite happy that they didn't implement some half-finished concept.
  - pjmlp 9y ago
    Adding generics to Java and C after several years, shows how successfully the "wait and see" actually works, versus languages that have supported them from the get go. CLU was designed in 1975 and ML in 1973, several languages with support for some kind of generics have been born and died since then. So in 42 years, there wasn't a single generic implementation that could fit Go's design goals, other than not having generics at all?!
    - owaislone 9y ago
      But Go has not existed for 42 years. Fitting any of those models on Go is exactly what should be avoided unless one of those models magically was a perfect fit for Go which came out just a few years ago.
      - pjmlp 9y ago
        That is just hand waving, it is more than clear that //go:generate, 90's style is the the only way accepted by Go design team. There is nothing special in Go's type system that hasn't been tried out in 42 years of generics CS research.
      - coldtea 9y ago
        Magically? It would take magic for one of these models to NOT be a perfect fit for Go. The fact that Go "has not existed for 42 years" is irrelevant -- almost all of its characteristics have been present for 3 to 5 decades, even altogether in the same language(s). E.g. http://cowlark.com/2009-11-15-go/ http://cowlark.com/2009-11-15-go/
        geodel 9y ago
        Seems author has added an update after 6 years: "..Updated 2015-09-25: So, about six years later, people are still reading this. I'm not sure how to feel about this; Looking at it now, it's incoherent, badly argued, and a lot of the details are simply wrong. But 1000 hits a month indicate that people still get value out of it." But this article link is still quite handy for random proof of Go badness.
        coldtea 9y ago
        Whatever the author added, the original points still stand. He might have changed his mind, but the facts are more stubborn.
        coldtea 9y ago
  - golergka 9y ago
    These two statements are arguments for different discussions: > I don't see how generics are needed to deal with "complex business logic". Here, we're talking about what user (developer who chooses between Go and Java) needs or wants. User doesn't care about costs behind the product. However, instead of proving this statement, you jump to a different perspective whatsoever: > But, as they have clearly laid out, this is not a trivial undertaking. There hasn't yet been an implementation concept presented, which fits into the Go framework with its design goals. And here you're estimating things from the cost perspective; and it quite logically follows that it's not rational for Go developers to dive into generics at the moment. Just keep it mind that this decision means that Go stays unappealing to users like me.
    - _ph_ 9y ago
      No, I am not talking about costs at all. First of all, I don't see how complex business logic requires generics. I have written complex business applications and not required them. I really have no idea why you would "need" them. And also for the Go developers, it is not about "cost". They have no idea how they could implement generics without fundamentally changing the Go language to something different than what it was about before. They are working on concepts, but nothing resulted what would be a candidate for implementation.
      - willtim 9y ago
        This boils down to how much one values static types and code reuse. If you do not have Generics (a.k.a. parametric polymorphism) then you are forced to make a choice between type safety and code reuse. You cannot have them both.
  - cdoxsey 9y ago
    Don't disagree but what often goes unnoticed in this discussion is that there are generics designs out there: https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-.... It's not so much "we should add generics but no one is really working on it" it's more "we should add generics and we've tried a dozen designs that haven't really panned out and we're still working on it". That's what makes me think they will end up happening.
  - willtim 9y ago
    > I don't see how generics are needed to deal with "complex business logic". Complex business logic really has no place in Go. I would advise people to use more expressive languages (ideally with a modern type system). Go was designed for low-level network systems programming and is not well suited to more high-level problems, despite what the hype train might claim. I see the future as a polyglot one. Folks should use the most appropriate language for whatever domain they are currently working in and not let their careers be defined by any one language or technology.
    - divan 9y ago
      Can you elaborate on what do you mean by "complex business logic"? Any examples?
      - willtim 9y ago
        I didn't bring the term up, but I personally understand it to mean complex domain-specific code. Some examples from my own workplace: pricing/risk of derivatives transactions, financial contract definition, portfolio optimisation, interpreters/compilers for various complex data transformations.
    - geodel 9y ago
      And Java was designed for toasters. But enough people worked on it made it one of the most popular general purpose language of all times. A lot of folks do not have time to evaluate most appropriate language for a given task at hand and they would rather write code for their needs in a general purpose language and be done with it.
      - willtim 9y ago
        Sure they tried to make it work. But it did create a static typing and OOP backlash. IMHO, too many of us succumbed to the marketing. Many would have been better off using OCaml or Python, both of which were released about the same time (and OCaml has always shipped with "generics"!).
- growse 9y ago
  I imagine the downvotes are because it doesn't really add anything insightful. It just looks like whining. Personally, I don't get the fuss. If you want generics, go use Java/Kotlin/something else. I don't see anyone complaining about the lack of generics in C or brainfuck, what makes golang special?
  - pjmlp 9y ago
    Because C actually has better support than Go for generics. They could be faked with macros since the early days, which was what Borland's BIDS framework in Borland C++ 2.0 for MS-DOS made use of, dropped when version 3.0 with initial template support was released (around 1992). Additionally, C now has basic language support for generics in C11 with _Generic.
    - growse 9y ago
      Fair enough, my C knowledge is a little behind the curve.
    - jernfrost 9y ago
      Except adding tools for doing some kind of macros is much simpler in Go than C because the language is easier to parse. What stops you from using a preprocessor in Go? It is not really part of the compiler in C either.
      - pjmlp 9y ago
        Sure it is, ANSI C11 (ISO/IEC 9899:2011) chapter 6.1 and section 6.5.1.1.
  - threeseed 9y ago
    This isn't a hard concept to understand. People like 90% of Go e.g. simplicity, build process, speed and feel that if they added features such as generics, decent error handling e.g. Option or Exceptions then it might go to 95%. Everyone is looking for that perfect development platform.
  - 9y ago
- fpoling 9y ago
  People have been using Basic and similar for ages to successfully implement business logic without generics. What is necessary for business applications is good integration with databases and reading/writing in various data formats. That typically depends on reflection facilities provided by the language, not genetics. In fact genetics, unless done with extreme care, inevitably makes reflection API more complex. In turn that makes it harder to write readers/writers for typical business formats harming the case of business applications.
  - pjmlp 9y ago
    Basic got generics long time ago in Visual Basic.NET. I have been coding since early 80's, naturally I have delivered lots of production code without generics. Oberon, one of my favorite language family and influence to Go, which I used for a while, also did not had generics. But that was in 1996, when generic programming was WIP in ANSI C++, ML compilers were starting to be adopted, Ada was too expensive, Java and .NET were yet to come. In 2017 I only use static typed languages without support for genericity when forced to do so.
  - zimpenfish 9y ago
    Isn't there some fact about how COBOL (which I'm reasonably sure doesn't have generics) still handles more transactions and/or more $$ per year than anything else?
- jernfrost 9y ago
  Use another language then. What is the point of different languages if they are supposed to have the same feature set? If you want native code type safety and generics use Rust instead. If that is too complicated use a more friendly type safety focused language like Swift. Really you are spoiled for choice and there is no need to insist every language should follow your particular language philosophy.
folago 9y ago
Adding generics is being considered and might be happening. In the meantime you could write an Experience report[0]? [0]https://github.com/golang/go/wiki/ExperienceReports https://github.com/golang/go/wiki/ExperienceReports
baby 9y ago
hell no, if generics get into go I'll have to find another favorite language.
- pjmlp 9y ago
  Good luck, even C11 has light generics nowadays.
  - leshow 9y ago
    light generics? C++ has very powerful generics and has had them for a long time, going under the name 'template metaprogramming'.
    - jjnoakes 9y ago
      He said C11, not C++(11).
    - pjmlp 9y ago
      I am speaking about C, not C++.
- ComputerGuru 9y ago
  Yeah, I can see how having features added to your favorite language while remaining fully compatible with the code you write today would warrant such a reaction. I mean, just having them in your language, even if you don’t have to use them is just so horrible.
  - Skinney 9y ago
    I think it would be naive to believe that adding generics to Go would have no effect on the stdlib, third party packages, and ultimately how you write Go code.
  - omginternets 9y ago
    In his defense, just because you don't write generics yourself doesn't mean you don't encounter them.
Shoothe 9y ago
It's interesting that generics are so important now but they were almost dropped from .NET schedule as being "academic only": https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc-generics-history-some-photos-from-feb-1999/ https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc-gener...
- willtim 9y ago
  C# was originally trying to copy Java, a language that took influence from C (weak types retrofitted) and Smalltalk (no static types at all). Industry has since learned a lot about the tremendous value that types bring. Other forms of static analysis are now gaining popularity too.
- pjmlp 9y ago
  Lets not forget that was in 1999, 10 years before Go came into existence.
  - Shoothe 9y ago
    For the record I'm not trying to argue generics are not important, on the contrary having worked with them for years go seems to be too limiting in this matter for my practical use. But I agree they can be tricky to get right (compare e.g. declaration-site vs use-site variance [0]) or "accidentaly Turing-complete" TypeScript [1]. [0]: https://schneide.wordpress.com/2015/05/11/declaration-site-and-use-site-variance-explained/ https://schneide.wordpress.com/2015/05/11/declaration-site-a... [1]: https://gist.github.com/hediet/63f4844acf5ac330804801084f87a6d4 https://gist.github.com/hediet/63f4844acf5ac330804801084f87a...
- bonesss 9y ago
  > ...they were almost dropped from .NET schedule as being "academic only" For all the good that has come out of .NET, and the nice platform it is today, there are a lot of high level design decisions where the team decidedly landed on 'the wrong answer'. To their credit they've been moving towards 'the right answer' for a while now. Auto-wrapped properties instead of exposed value fields. Smart initialization. Safe default values. Generics. Anonymous functions. Nulls. Higher order functions. Still under way: pattern matching, DSL support, option type, type aliasing, etc. Related, but I also find it highly fascinating on those topics how much of Visual Basic's design they ignored, derided, and have then had to re-implement after-the-fact. A lot of babies got thrown out with the COM+/VB6/MFC bathwater.
krzat 9y ago
Generics cause autism.
- dunkelsten 9y ago
  Autism causes vaccines.
- jrs95 9y ago
  Some people’s attitude about this would make you think they actually believe this
  - justin66 9y ago
    Some people's attitude about this would make you think they are actually suffering from this.

I don't know why you're downvoted. Generics is a feature that's holding back a lot of developers dealing with complicated business logic (and need for abstraction) from moving to Go. And at the same time, including generics into the language means that all libraries will add generics interfaces - and most probably, stop supporting the old, non-generic interfaces in some time into the future, breaking backwards compatibility at some point.

_ph_ 9y ago
I am one who downvoted that statement, because I considered it a snippy remark without any content. Especially, as the question of generics in Go has been mentioned and discussed often enough. And if one feels the need to restart that discussion with each Go release, one should do so with an insightful comment. I do not agree with your comment. I don't see how generics are needed to deal with "complex business logic". Yes, ultimately I would like to see generics added to the Go language. As does the Go development team. But, as they have clearly laid out, this is not a trivial undertaking. There hasn't yet been an implementation concept presented, which fits into the Go framework with its design goals. And until then, I am quite happy that they didn't implement some half-finished concept.
- pjmlp 9y ago
  Adding generics to Java and C after several years, shows how successfully the "wait and see" actually works, versus languages that have supported them from the get go. CLU was designed in 1975 and ML in 1973, several languages with support for some kind of generics have been born and died since then. So in 42 years, there wasn't a single generic implementation that could fit Go's design goals, other than not having generics at all?!
  - owaislone 9y ago
    But Go has not existed for 42 years. Fitting any of those models on Go is exactly what should be avoided unless one of those models magically was a perfect fit for Go which came out just a few years ago.
    - pjmlp 9y ago
      That is just hand waving, it is more than clear that //go:generate, 90's style is the the only way accepted by Go design team. There is nothing special in Go's type system that hasn't been tried out in 42 years of generics CS research.
    - coldtea 9y ago
      Magically? It would take magic for one of these models to NOT be a perfect fit for Go. The fact that Go "has not existed for 42 years" is irrelevant -- almost all of its characteristics have been present for 3 to 5 decades, even altogether in the same language(s). E.g. http://cowlark.com/2009-11-15-go/ http://cowlark.com/2009-11-15-go/
      - geodel 9y ago
        Seems author has added an update after 6 years: "..Updated 2015-09-25: So, about six years later, people are still reading this. I'm not sure how to feel about this; Looking at it now, it's incoherent, badly argued, and a lot of the details are simply wrong. But 1000 hits a month indicate that people still get value out of it." But this article link is still quite handy for random proof of Go badness.
        coldtea 9y ago
        Whatever the author added, the original points still stand. He might have changed his mind, but the facts are more stubborn.
        coldtea 9y ago
- golergka 9y ago
  These two statements are arguments for different discussions: > I don't see how generics are needed to deal with "complex business logic". Here, we're talking about what user (developer who chooses between Go and Java) needs or wants. User doesn't care about costs behind the product. However, instead of proving this statement, you jump to a different perspective whatsoever: > But, as they have clearly laid out, this is not a trivial undertaking. There hasn't yet been an implementation concept presented, which fits into the Go framework with its design goals. And here you're estimating things from the cost perspective; and it quite logically follows that it's not rational for Go developers to dive into generics at the moment. Just keep it mind that this decision means that Go stays unappealing to users like me.
  - _ph_ 9y ago
    No, I am not talking about costs at all. First of all, I don't see how complex business logic requires generics. I have written complex business applications and not required them. I really have no idea why you would "need" them. And also for the Go developers, it is not about "cost". They have no idea how they could implement generics without fundamentally changing the Go language to something different than what it was about before. They are working on concepts, but nothing resulted what would be a candidate for implementation.
    - willtim 9y ago
      This boils down to how much one values static types and code reuse. If you do not have Generics (a.k.a. parametric polymorphism) then you are forced to make a choice between type safety and code reuse. You cannot have them both.
- cdoxsey 9y ago
  Don't disagree but what often goes unnoticed in this discussion is that there are generics designs out there: https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-.... It's not so much "we should add generics but no one is really working on it" it's more "we should add generics and we've tried a dozen designs that haven't really panned out and we're still working on it". That's what makes me think they will end up happening.
- willtim 9y ago
  > I don't see how generics are needed to deal with "complex business logic". Complex business logic really has no place in Go. I would advise people to use more expressive languages (ideally with a modern type system). Go was designed for low-level network systems programming and is not well suited to more high-level problems, despite what the hype train might claim. I see the future as a polyglot one. Folks should use the most appropriate language for whatever domain they are currently working in and not let their careers be defined by any one language or technology.
  - divan 9y ago
    Can you elaborate on what do you mean by "complex business logic"? Any examples?
    - willtim 9y ago
      I didn't bring the term up, but I personally understand it to mean complex domain-specific code. Some examples from my own workplace: pricing/risk of derivatives transactions, financial contract definition, portfolio optimisation, interpreters/compilers for various complex data transformations.
  - geodel 9y ago
    And Java was designed for toasters. But enough people worked on it made it one of the most popular general purpose language of all times. A lot of folks do not have time to evaluate most appropriate language for a given task at hand and they would rather write code for their needs in a general purpose language and be done with it.
    - willtim 9y ago
      Sure they tried to make it work. But it did create a static typing and OOP backlash. IMHO, too many of us succumbed to the marketing. Many would have been better off using OCaml or Python, both of which were released about the same time (and OCaml has always shipped with "generics"!).
growse 9y ago
I imagine the downvotes are because it doesn't really add anything insightful. It just looks like whining. Personally, I don't get the fuss. If you want generics, go use Java/Kotlin/something else. I don't see anyone complaining about the lack of generics in C or brainfuck, what makes golang special?
- pjmlp 9y ago
  Because C actually has better support than Go for generics. They could be faked with macros since the early days, which was what Borland's BIDS framework in Borland C++ 2.0 for MS-DOS made use of, dropped when version 3.0 with initial template support was released (around 1992). Additionally, C now has basic language support for generics in C11 with _Generic.
  - growse 9y ago
    Fair enough, my C knowledge is a little behind the curve.
  - jernfrost 9y ago
    Except adding tools for doing some kind of macros is much simpler in Go than C because the language is easier to parse. What stops you from using a preprocessor in Go? It is not really part of the compiler in C either.
    - pjmlp 9y ago
      Sure it is, ANSI C11 (ISO/IEC 9899:2011) chapter 6.1 and section 6.5.1.1.
- threeseed 9y ago
  This isn't a hard concept to understand. People like 90% of Go e.g. simplicity, build process, speed and feel that if they added features such as generics, decent error handling e.g. Option or Exceptions then it might go to 95%. Everyone is looking for that perfect development platform.
- 9y ago
fpoling 9y ago
People have been using Basic and similar for ages to successfully implement business logic without generics. What is necessary for business applications is good integration with databases and reading/writing in various data formats. That typically depends on reflection facilities provided by the language, not genetics. In fact genetics, unless done with extreme care, inevitably makes reflection API more complex. In turn that makes it harder to write readers/writers for typical business formats harming the case of business applications.
- pjmlp 9y ago
  Basic got generics long time ago in Visual Basic.NET. I have been coding since early 80's, naturally I have delivered lots of production code without generics. Oberon, one of my favorite language family and influence to Go, which I used for a while, also did not had generics. But that was in 1996, when generic programming was WIP in ANSI C++, ML compilers were starting to be adopted, Ada was too expensive, Java and .NET were yet to come. In 2017 I only use static typed languages without support for genericity when forced to do so.
- zimpenfish 9y ago
  Isn't there some fact about how COBOL (which I'm reasonably sure doesn't have generics) still handles more transactions and/or more $$ per year than anything else?
jernfrost 9y ago
Use another language then. What is the point of different languages if they are supposed to have the same feature set? If you want native code type safety and generics use Rust instead. If that is too complicated use a more friendly type safety focused language like Swift. Really you are spoiled for choice and there is no need to insist every language should follow your particular language philosophy.

folago 9y ago

Adding generics is being considered and might be happening. In the meantime you could write an Experience report[0]? [0]https://github.com/golang/go/wiki/ExperienceReports https://github.com/golang/go/wiki/ExperienceReports

baby 9y ago

hell no, if generics get into go I'll have to find another favorite language.

pjmlp 9y ago
Good luck, even C11 has light generics nowadays.
- leshow 9y ago
  light generics? C++ has very powerful generics and has had them for a long time, going under the name 'template metaprogramming'.
  - jjnoakes 9y ago
    He said C11, not C++(11).
  - pjmlp 9y ago
    I am speaking about C, not C++.
ComputerGuru 9y ago
Yeah, I can see how having features added to your favorite language while remaining fully compatible with the code you write today would warrant such a reaction. I mean, just having them in your language, even if you don’t have to use them is just so horrible.
- Skinney 9y ago
  I think it would be naive to believe that adding generics to Go would have no effect on the stdlib, third party packages, and ultimately how you write Go code.
- omginternets 9y ago
  In his defense, just because you don't write generics yourself doesn't mean you don't encounter them.

Shoothe 9y ago

It's interesting that generics are so important now but they were almost dropped from .NET schedule as being "academic only": https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc-generics-history-some-photos-from-feb-1999/ https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc-gener...

willtim 9y ago
C# was originally trying to copy Java, a language that took influence from C (weak types retrofitted) and Smalltalk (no static types at all). Industry has since learned a lot about the tremendous value that types bring. Other forms of static analysis are now gaining popularity too.
pjmlp 9y ago
Lets not forget that was in 1999, 10 years before Go came into existence.
- Shoothe 9y ago
  For the record I'm not trying to argue generics are not important, on the contrary having worked with them for years go seems to be too limiting in this matter for my practical use. But I agree they can be tricky to get right (compare e.g. declaration-site vs use-site variance [0]) or "accidentaly Turing-complete" TypeScript [1]. [0]: https://schneide.wordpress.com/2015/05/11/declaration-site-and-use-site-variance-explained/ https://schneide.wordpress.com/2015/05/11/declaration-site-a... [1]: https://gist.github.com/hediet/63f4844acf5ac330804801084f87a6d4 https://gist.github.com/hediet/63f4844acf5ac330804801084f87a...
bonesss 9y ago
> ...they were almost dropped from .NET schedule as being "academic only" For all the good that has come out of .NET, and the nice platform it is today, there are a lot of high level design decisions where the team decidedly landed on 'the wrong answer'. To their credit they've been moving towards 'the right answer' for a while now. Auto-wrapped properties instead of exposed value fields. Smart initialization. Safe default values. Generics. Anonymous functions. Nulls. Higher order functions. Still under way: pattern matching, DSL support, option type, type aliasing, etc. Related, but I also find it highly fascinating on those topics how much of Visual Basic's design they ignored, derided, and have then had to re-implement after-the-fact. A lot of babies got thrown out with the COM+/VB6/MFC bathwater.

krzat 9y ago

Generics cause autism.

dunkelsten 9y ago
Autism causes vaccines.
jrs95 9y ago
Some people’s attitude about this would make you think they actually believe this
- justin66 9y ago
  Some people's attitude about this would make you think they are actually suffering from this.