[HN Gopher] An Introduction to Generics
___________________________________________________________________
An Introduction to Generics
Author : mfrw
Score : 113 points
Date : 2022-03-25 16:37 UTC (6 hours ago)
(HTM) web link (go.dev)
(TXT) w3m dump (go.dev)
| klabb3 wrote:
| Everyone has strong opinions about language features. Personally,
| I'm happy that we had an imperative, statically typed mainstream
| language without generics for a long time. It really showed how
| much you can achieve without it in practical terms. Obviously,
| interfaces and built-in generic types like maps & slices, helped
| compensate a lot, but it's a quite simple feature set. I feel
| like I have a much clearer view today on when generics really
| shine compared to other alternatives. I hope, going forward, that
| responsible idioms around generics will be established in the Go
| community.
| rank0 wrote:
| Generics feel like OOP creeping back into popular programming
| culture.
|
| Everything just goes in a big circle. OOP is the bees knee's for
| like 20 years and then everyone decides that OOP is the devil for
| unnecessary abstraction. Then everyone gets all exited about
| functional programming, but they miss some of the convenience of
| abstract classes and inheritance.
|
| After developers make sufficient noise, we wind up with
| effectively the same OOP functionality *GASP. We just avoid words
| like "class"....
|
| EDIT: You guys are right about generics in FP. I guess my larger
| point is that lots language paradigms provide the same features
| just with different names and backlash is silly.
| eweise wrote:
| Generics has nothing to do with OOP
| pie_flavor wrote:
| Object-orientation has nothing to do with generics. Generics
| are static typing v2, object-orientation is an entire
| programming paradigm encompassing program design, idioms, the
| fundamental way you think about flow, etc., and doesn't require
| static typing v1 either. JS, the most object-oriented language
| under the sun, doesn't have generics; C, the least, does.
| yashap wrote:
| Generics are wildly, WILDLY popular in functional programming -
| far more so than in imperative flavours of OOP, really.
| Basically every functional data structure is full of things
| like List[A].map(func: A => B): List[B]
|
| Also, it's really not "OOP or functional", there are tonnes of
| languages mixing OOP and functional very effectively (Scala is
| both very functional and very object oriented, but honestly
| most languages are a mix to some degree). Functional vs.
| imperative is more of a divide.
| jaytaylor wrote:
| And yet, FP remains less popular overall than OOP
| (personally, I love love FP :).
|
| Many of the people targeting the most popular FP language of
| all time aren't writing the Javascripts because it's their
| first choice. Just look at the pretty WILD popularity of
| Typescript, an OOP bolt-on language which transpiles to
| Javascript.
|
| The simpler (in some ways) imperative programming model still
| dominates developer mindset.
| vereis wrote:
| TypeScript bringing a half decent type system to JavaScript
| is orthogonal to OOP
|
| JavaScript is OOP already. TypeScript just provides better
| typing like what you would find in Haskell, Ocaml or other
| functional languages
| jaytaylor wrote:
| You are technically 100% correct, however the bultin
| object system in Javascript is so bad that a reasonable
| argument can be made that it's not particularly
| accessible or ergonomic to many of the folks who actually
| write it for a living.
|
| I know lots of folks here on HN are super highly
| competent, and this contrasts with my IRL experience with
| colleagues who are less passionate about programming and
| just want to do their job- these folks aren't going to be
| teaching lessons in proper usage of objects in JS.
| herbstein wrote:
| Generics have been used in functional programming before OOP
| and classes were but a twinkle in a researchervs eye
| Jtsummers wrote:
| They've also been in procedural languages for over 40 years.
| Ada started with generics and the first spec was published in
| 1983.
| jaytaylor wrote:
| type Ordered interface { Integer|Float|~string
| }
|
| I kind of despise the keyword / syntax design choice of the tilde
| (~) signifying "anything where the underlying type is e.g. a
| string".
|
| Usually a ~ signifies a bitwise-NOT operation*.
|
| It reminds me of something more like a Ruby design mentality,
| where optimizing for code terseness is chosen. The nice thing
| about the crazy syntax in Ryby is that at least the chosen symbol
| is unique and doesn't conflict with meaning in other similar
| languages.
|
| I realize the context where it's used is not part of the logic-
| execution pipeline, but it still forces me to contort my mind and
| special case this concept, and map it against what is effectively
| a namespace collision between Go and other C-style languages.
|
| Naturally it's too late for Go (Generics are fully baked and
| released), but would have been nice to land with something more
| intuitive or at least less collision-prone, even if only to avoid
| the ambiguity.
|
| Inevitably, the introduction of generics means increased
| opportunities for new kinds of complexity, and this choice
| needlessly increases the cognitive load when trying to read and
| reason about a go program.
|
| I know it's the the end of the world, but I find it somewhat of a
| bummer for a technology I was previously so enthusiastic about.
|
| _* edit: Thank you Jtsummers for the correction- it is bitwise-
| NOT, I had mistakenly written bitwise-OR._
| Jtsummers wrote:
| > Usually a ~ signifies a bitwise-OR operation.
|
| That sounded wrong to me, I recalled it being a NOT, and double
| checked. Turns out my recollection was correct (it's also not
| something I ever used much), it is the bitwise-NOT in C.
|
| That actually makes it a bit more awkward, in my mind, as I
| initially parsed the example as "not string". However, ~ is
| also often used to mean "about" or "approximately". In a text
| exchange:
|
| "How many people will be at dinner?"
|
| "~5"
|
| Meaning "about 5 people" or "approximately 5 people". So this
| also works in that sense, ~string can be read as "something in
| the neighborhood of a string" or "something like a string".
|
| https://en.wikipedia.org/wiki/Bitwise_operations_in_C
| [deleted]
| infogulch wrote:
| > Usually a ~ signifies a bitwise-NOT operation*.
|
| Only in expression context. C doesn't assign any meaning to ~
| in type definition context, nor does it have an existing way to
| represent the concept of "any type reducible to X". Since it
| doesn't diverge from C in either syntactic or semantic meanings
| when considering context, I don't see this being an issue in
| practice. Any potential confusion argument you can lay onto ~
| could also be used against |, but I don't see any mention of
| that being a problem.
|
| I can't "disagree" with your reaction -- that would be silly
| even if I wanted to -- but I claim that you would likely stop
| suffering from increased mental effort as you read and write
| this syntax over time.
| altun wrote:
| ~ is the similarity sign as mathematical symbols.
| jaytaylor wrote:
| Agreed, this is a slightly better way to think about it, yet
| still seems out of place for Go. Where else does Golang
| diverge from what an operator means in C?
| [deleted]
| Thaxll wrote:
| If you ask most programmer, ~ is definitely not a bitwise-NOT
| operation.
| xiaq wrote:
| Well, * can already mean any of "pointer to" (in type context),
| "dereference" (as a unary prefix operator) or "multiplication"
| (as a binary operator)...
| sudhirj wrote:
| An example of something that I couldn't do with earlier non-
| generic versions of Go: implement the lodash functions in Go with
| a nice DX[1]. I kept using []T though, and the article has a good
| example of how to improve that to work with slice based type, not
| just slices.
|
| So many simple daily use methods like map, forEach, any, all,
| reduce etc feel much better now.
|
| On the whole generics here seem neat, well thought out, easy to
| understand and usable, while still allowing you to completely
| ignore them if you want. Most declarations fit neatly into
| libraries, with usage often never even having to mention or even
| know about type declarations (See the examples on the lib). That
| was a nice change from Java - the inference is pretty nice and
| neat from what I've seen so far.
|
| I'm sure we'll find it being pushed to its limits, like with ORMs
| and multi chaining, and that might be ugly, but on the whole I'm
| very satisfied with this addition.
|
| [1]: https://GitHub.com/sudhirj/slicy
| [deleted]
| eweise wrote:
| No type definitions for methods :(
| pie_flavor wrote:
| Methods exist to implement interfaces. Interfaces cannot have
| generic methods because those would need to be instantiated at
| runtime, which would require runtime codegen.
| sciolizer wrote:
| Why do you need runtime codegen? What exactly needs to be
| "instantiated"? Ultimately the runtime representation of a
| type parameter comes down to sizes and offsets. Why not have
| the caller pass those values into the generic method?
| [deleted]
___________________________________________________________________
(page generated 2022-03-25 23:00 UTC)