generics

[christophberger]

Written on 02/25/2017 13:28:28

URL: https://appliedgo.net/generics/

[christophberger]

Migrated comment, written by Juan Carlos Diaz on 04/29/2019 20:30:09

When you say "who needs generics" and then your solution is to use reflection, you have to know you're doing it wrong

[christophberger]

Migrated comment, written by Zorion on 08/02/2019 08:28:51

I think this may work:


type Responses {
status int
data interface{}
}


See example

[christophberger]

Migrated comment, written by JD Reddaway on 09/28/2019 15:47:23

The html/formatting is broken toward the bottom of the article

[christophberger]

Migrated comment, written by gromas on 11/18/2019 11:25:24

A year ago...

And since a few months, the first official generics design for Go has been released

[christophberger]

Migrated comment, written by Marcus Manning on 12/14/2019 17:01:33

Hmm, how do you personally think about go adding generics?
https://blog.golang.org/why...

[christophberger]

Migrated comment, written by Dan Markhasin on 01/27/2020 11:34:59

You should remove the option of copy&paste, it is an approach that should never even be considered. If you are even considering copy&pasting code, you're doing something wrong.

[christophberger]

Migrated comment, written by Travis Burns on 02/27/2020 15:13:56

well... still waiting... if nothing comes out from Google we will probably relapse to JVM or Microsoft stack

[christophberger]

Migrated comment, written by Travis Burns on 02/27/2020 15:30:45

Nah code generation is fine. Spring Boot wsdl stack requires one to generate classes using maven/gradle to describe an operation. Also pretty much all modern BPM solutions have code generator under the hood. Subtle template changes can be done before file generation. After that designers can do their magic on a materialized template file or keep it default. I gave you the use cases but these are not excuses for a proper implementation of Generics.

[christophberger]

Migrated comment, written by Alexandros Ntousias on 04/27/2020 08:49:07

4 years later and....still no generics in Go. Personally, I'm tired of people making lame excuses to defend an incomplete language, instead of just admitting "Generics is a fundamental tool in any programming's and developer's toolbox".
As some people already pointed out in the comments, if generics were not important, the language wouldn't use them itself...but it does in various places, i.e. range, len, etc.

Also, regarding the "limited number of use cases that generics are useful", this is a blatant lie! Generics are everywhere! It would actually be the opposite...there is only a VERY limited number of use cases that generics are not important, and in these use cases the systems are so ridiculously simple that you could use ANY language you want, no need for the pros that Go is giving you.

Finally, I wish people would finally stop justifying all the deficiencies of Go as "Go aims to be a simple language". No, there is a difference between a simple language like Kotlin, Ruby or Python, and a lazy-written language like Go!

I'm pretty sure that if Go wasn't backed by Google in the first place, it would have the adoption of the Whitespace language!

[christophberger]

Migrated comment, written by vectorjohn on 05/02/2020 06:22:45

Not to resurrect a dead thread, but I have to disagree with the whole framing of this comment.

The question is not if generics are necessary. All turing complete languages can do anything that any other turing complete language can, so literally none of the language features are "needed". You can get by with basically "compare" and "goto".

Generics apply to literally every single programming domain. I don't think you can name one that wouldn't benefit from generics as the simple array proves.

[christophberger]

Migrated comment, written by Christoph on 05/25/2020 21:01:19

Sure, adding loops, functions, and data types to a basic "compare and goto" language adds immense value, no question. The point here is, each benefit comes with a cost. Generics bring convenience, no doubt, but they also add complexity. The two questions are, are generics worth the cost, and if so, how do we minimize the cost? This second question is the really hard one, and the Go team has been taking plenty of time to answer this question right. In this article, the Go team explains their design goals (scroll down to "Benefits and costs").