5 ms·

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 menti

by _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
        Especially since he adds "Don't get me wrong; I still think that Go is a terrible language. I now work for a company that does a lot of it, and every time I touch it it depresses me a little more".
- willtim 9y ago
  The "wait and see" approach as you call it, means that "Generics" (a.k.a. parametric polymorphism) have had to be retro-fitted to languages like Java. This means they are more complex than they need to be and have some ugly edge cases.
  - pjmlp 9y ago
    In C11 they are even uglier with the _Generic selector, which understandably was made to work together with how generics were done via pre-processor macros.
  - erik_seaberg 9y ago
    This. We still can't overload foo(List<Integer> x) and foo(List<String> x) because vintage 2004 JVMs wouldn't be able to distinguish them. Type erasure was a horrible compromise from which Java will probably never completely recover.
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"!).

by _ph_ 9y ago

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
        Especially since he adds "Don't get me wrong; I still think that Go is a terrible language. I now work for a company that does a lot of it, and every time I touch it it depresses me a little more".
willtim 9y ago
The "wait and see" approach as you call it, means that "Generics" (a.k.a. parametric polymorphism) have had to be retro-fitted to languages like Java. This means they are more complex than they need to be and have some ugly edge cases.
- pjmlp 9y ago
  In C11 they are even uglier with the _Generic selector, which understandably was made to work together with how generics were done via pre-processor macros.
- erik_seaberg 9y ago
  This. We still can't overload foo(List<Integer> x) and foo(List<String> x) because vintage 2004 JVMs wouldn't be able to distinguish them. Type erasure was a horrible compromise from which Java will probably never completely recover.

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"!).