Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go generics are not bad

lemire.me

Post reply on HN
Print view View original

171–180 of 305 posts

Re: Go generics are not bad

#171

Post by cookiengineer »

kgeist wrote: post #166
cookiengineer wrote: post #143

Earlier quoted context omitted.

Generics are useless when there is no way to integrate them with your rest of the code. As golang has no instanceof or typeof keyword, you practically you cannot use a method that uses multiple types as arguments without having to use the reflect API, just to have an if/else branch on what to do with that argument. The things that I mentioned are from another point of view where language designers and implementers de…

>As golang has no instanceof or typeof keyword, you practically you cannot use a method that uses multiple types as arguments without having to use the reflect API You don't have to use reflection, there are typecasts: "value, ok := arg.(MyType)" You can also switch on a type. How is it different from instanceof in practice?

The point of described scenario was to have a _different_ if/elseif branch, and not the identical behaviour for one struct type.

If item instanceof HouseStruct {}

Elseif item instanceof ContainerStruct {}

With your suggested solution you end up with OOP fatigue and GenericBuildingImplementationStruct which is probably not what golang wanted to embrace with their type system.

Re: Go generics are not bad

#172

Post by kgeist »

cookiengineer wrote: post #171
kgeist wrote: post #166

Earlier quoted context omitted.

>As golang has no instanceof or typeof keyword, you practically you cannot use a method that uses multiple types as arguments without having to use the reflect API You don't have to use reflection, there are typecasts: "value, ok := arg.(MyType)" You can also switch on a type. How is it different from instanceof in practice?

The point of described scenario was to have a _different_ if/elseif branch, and not the identical behaviour for one struct type. If item instanceof HouseStruct {} Elseif item instanceof ContainerStruct {} With your suggested solution you end up with OOP fatigue and GenericBuildingImplementationStruct which is probably not what golang wanted to embrace with their type system.

I'm not sure I follow what you mean. In Go the equivalent to your example is:

  switch val := item.(type) {
    case HouseStruct:
    case ContainerStruct:
  }

Re: Go generics are not bad

#173

Post by fauigerzigerk »

TheDong wrote: post #144
mseepgood wrote: post #100

Earlier quoted context omitted.

I don't think that's what the blub paradox is. I think the parent comment is arguing the opposite. People who believe in the blub paradox are usually so smug and full of themselves that they don't pursue simple solutions.

The parent commenter is dismissing generics, and various other features, as something that "bogs people down" and makes them write worse code. This is the essence of the blub paradox, thinking that people who use a feature are simply misusing it, after all in blub you don't have generics and things are fine. They're just making things more complicated than they need to be. The blub programmer isn't necessarily smug,…

The problem with the blub argument is that it heavily relies on the existence of an undisputed power hierarchy among programming languages. Only s/he who is an expert in the most powerful language is in a position to pass judgement on all other languages.

I don't know how to resolve disputes over the relative power of programming languages on that basis. Are dynamic languages more or less powerful than static languages with advanced type systems? I don't know. What's the definition of power?

But I think what we can take from blub is that familiarity with one language or set of features is an insufficient basis for dismissing other, unfamiliar, languages or features.

Re: Go generics are not bad

#174

Post by blep_ »

maxbond wrote: post #88
nine_k wrote: post #71

Earlier quoted context omitted.

AFAICT this is basically how numbers work in Haskell, and I see no particular problems with them. You usually don't need too many number types of different nature.

Generics are great when you need them, but they will cut you badly if you misuse them. Generics are viral. When you make something generic, you often have to make the things that touch or contain it generic, too. Generics also create tight coupling. When you change the definition of a generic interface/class, you'll need to update your usage across the codebase. As opposed to, say, adding a new field to a class, that…

All of the things you said apply equally well to function parameters.

Re: Go generics are not bad

#175

Post by [deleted] »

rachitnigam wrote: post #38
anyfoo wrote: post #33

Earlier quoted context omitted.

> those functions of type 'a->'a Polymorphism. But note that there is only one function of type 'a->'a for all 'a, and that's the identity function.

Not quite. This also has the type ‘a -> ‘a: def nitpick(x): throw “foo”

[deleted]

Re: Go generics are not bad

#177

Post by xigoi »

orangecat wrote: post #104
danielscrubs wrote: post #87

Either you start making a language from a sound theoretical foundation and then implement it (Koka springs to mind) or you implement a language from some syntactic gripes and then try to find the theoretical foundation later… Go was impressive in the practical sense (compiler speed, channels in std and good tooling) but a shit show otherwise. I’ve completely lost any confidence that FANG will be able to make some gre…

I’ve completely lost any confidence that FANG will be able to make some great language because they always take the easy way (makes more business sense, see Dart). I've found Dart to be perfectly adequate. Like Go it doesn't try to be overly clever; unlike Go it doesn't consider verbosity to be a feature, and believes you're capable of using advanced techniques like ternary expressions responsibly.

If you consider conditional expressions an “advanced technique”, that explains a lot…

Re: Go generics are not bad

#178

Post by kgeist »

pjmlp wrote: post #158
danielscrubs wrote: post #87

Either you start making a language from a sound theoretical foundation and then implement it (Koka springs to mind) or you implement a language from some syntactic gripes and then try to find the theoretical foundation later… Go was impressive in the practical sense (compiler speed, channels in std and good tooling) but a shit show otherwise. I’ve completely lost any confidence that FANG will be able to make some gre…

Go 's compilation speed is only impressive for newer generations that never used compilers for Pascal dialects, Modula languages, BASIC,....

True but they didn't have to deal with the complexity of the modern software where a typical project can pull in thousands of dependencies (transitively).

Re: Go generics are not bad

#179

Post by xigoi »

anyfoo wrote: post #63
rachitnigam wrote: post #38

Earlier quoted context omitted.

Not quite. This also has the type ‘a -> ‘a: def nitpick(x): throw “foo”

You're right, and foo x = foo x also qualifies as 'a -> 'a. The only function that always terminates is the identity function, then.

A function in the mathematical sense is total (always terminates).

Re: Go generics are not bad

#180

Post by xigoi »

bediger4000 wrote: post #2

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 relev…

    func sum[Number](nums: openArray[Number]): Number =
      for num in nums:
        result += num
Took about a minute.
Post reply on HN