[HN Gopher] Go generics are not bad
       ___________________________________________________________________
        
       Go generics are not bad
        
       Author : ibobev
       Score  : 31 points
       Date   : 2022-07-08 21:55 UTC (1 hours ago)
        
 (HTM) web link (lemire.me)
 (TXT) w3m dump (lemire.me)
        
       | bediger4000 wrote:
       | This is good to hear.
       | 
       | There's something like a cognitive bias that makes me leary of
       | genetics (in any language). Once you have some cross cutting
       | feature, generics or object orientation, or in functional
       | programming, those functions of type 'a->'a, or assembly language
       | address modes, people get bogged down by trying to make
       | everything in their work generic or object oriented or
       | "orthogonal". Lemire's example is relevant to his topic, but it
       | could be a poster child if someone else did it. They need to sum
       | an array of int. So they spend 4 days getting a function and a
       | generic type that can sum every numerical type, rather than 15
       | minutes to sum int arrays.
       | 
       | What's this called?
        
         | nvartolomei wrote:
         | This was just discussed here in another front page post "Why
         | DRY is the most over-rated programming principle"
         | https://news.ycombinator.com/item?id=32010699
        
         | TheDong wrote:
         | > What's this called?
         | 
         | The blub paradox https://wiki.c2.com/?BlubParadox
        
         | alanbernstein wrote:
         | Premature abstraction?
        
         | nicoburns wrote:
         | > They need to sum an array of int. So they spend 4 days
         | getting a function and a generic type that can sum every
         | numerical type, rather than 15 minutes to sum int arrays.
         | 
         | More likely they install a 3rd party generic sum function and
         | don't have to write their own _at all_. Well, in the case of a
         | sum function it 's probably only 15 minutes to write to generic
         | version, and there may even be one in the standard library. But
         | consider something like a concurrent hash map. In Rust, You
         | just `cargo add dashmap` and you have one that works with any
         | type that works with a regular hashmap. This isn't possible
         | without generics.
        
       | saagarjha wrote:
       | This is like the most cherry-picked example that could've been
       | chosen. Java can't do this because the primitive types are not
       | objects. Mentioning the performance of this is hilarious because
       | 1. it's Daniel Lemire, he should know better and 2. the
       | performance of pretty much every other thing that uses generics
       | is terrible because of gcshapes being passed everywhere and 3.
       | Java literally has a JIT to make generics fast. And bear in mind
       | I don't even like Java generics that much, it's just that Go does
       | even worse. (But still better than when it didn't have it at all,
       | I guess...)
        
         | Thaxll wrote:
         | How can Go does it even worse that Java where generics
         | implementation is the worse of all modern language with type
         | erasure.
         | 
         | Java is way worse than Go on that aspect.
        
         | OskarS wrote:
         | It's a pretty darn relevant fact for Java programmers that Java
         | generics are implemented using type erasure and is therefore
         | seriously crippled compared to other how languages do it. The
         | fact that Go doesn't make the same mistake is excellent news.
        
       | glmdev wrote:
       | I think Go's generics are reasonable, but not quite powerful
       | enough to scale.
       | 
       | It's all well and good to generalize basic containers and
       | functions (good, in fact), but I wish the language was better at
       | inferring types.
       | 
       | I'm sure this is something that will improve with time, but a bit
       | after generics were released, I tried to build a type-safe
       | language evaluator in Go using generics and found them lacking
       | the kind of type-narrowing necessary for fully-generic
       | architecture.
       | 
       | Short write-up of my conundrum on SO, if anyone is interested:
       | https://stackoverflow.com/questions/71955121/how-to-type-swi...
       | 
       | TypeScript has me spoiled. :)
        
         | nemothekid wrote:
         | I haven't looked into Go's actual implementation but isn't this
         | kind of downcasted better suited for interfaces. Your code, as
         | is, wouldn't translate to something like Rust which uses
         | monomorphization; you are doing a runtime "inspection" of the
         | types. This looks more in the domain of duck-typing than
         | something that generics handles.
        
           | SekstiNi wrote:
           | Here's a writeup exploring this very topic, and showing how
           | Go's generics will currently give worse performance than just
           | using an interface.
           | 
           | https://planetscale.com/blog/generics-can-make-your-go-
           | code-...
        
         | bbkane wrote:
         | Yes, I was trying to get it to infer the types for some code I
         | was writing as well (a generic funcopt for two different types)
         | and it couldn't - made me specify the type manually.
        
       | avgcorrection wrote:
       | Key phrase in the article:
       | 
       | > So, at least in this one instance,
       | 
       | Yeah, one example which is not even that useful. It might be
       | cherry-picked for all I know.
        
       | lma21 wrote:
       | It's been a while since i've went through any Java code. Why
       | wouldn't the Java code sample compile?
        
         | saagarjha wrote:
         | Java primitive types are not objects :/
        
       ___________________________________________________________________
       (page generated 2022-07-08 23:00 UTC)