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

81–90 of 305 posts

Re: Go generics are not bad

#81

Post by levoea »

lma21 wrote: post #8

It's been a while since i've went through any Java code. Why wouldn't the Java code sample compile?

you can't do `T summer = 0`, nor `summer += v[k]` as there is no arbitrary sum operation for Number (e.g a method `Number add(Number);` or ` T add(T t);`).

though this can be solved either with types, as mentioned in another comment (https://news.ycombinator.com/item?id=32029871), or simply by providing the sum operation:

    static  T sum(T[] v, BinaryOperator adder) {
       T summer = v[0];
       for (int i = 1; i  x + y);

Re: Go generics are not bad

#82

Post by wyuenho »

Avlin67 wrote: post #51

proper generics would be C++ but it is called templates and could be hardcore.. https://stackoverflow.com/a/498329/729738 .Net generics do have same issues mentioned in the article

Proper generics would be parametric polymorphism with full program type inference, i.e. an ML derivative.

Re: Go generics are not bad

#83

Post by [deleted] »

tapirl wrote: post #61

This article is too simple to get a full picture of Go custom generics. There are actually both good points and bad points. To get a comprehensive understanding of the current Go custom generics, please read: https://go101.org/generics/101.html

[deleted]

Re: Go generics are not bad

#84

Post by throwaway894345 »

wahern wrote: post #64
bouncycastle wrote: post #34

The site gives assembly code of the inner loop, but isn't the problem that there is additional overhead on the calling of generic functions?

AFAIU, as compared to pure monomorphization, yes, sometimes the model imposes runtime indirection. This is particularly the case for methods. However, for simple yet common cases, such as functions taking []T, the model permits inlining into the caller.

I’m also hoping that the more monomorphization will take place over time.

Re: Go generics are not bad

#85

Post by enw »

throwaway234232 wrote: post #49

I think in Java, you would need to do a type-class approach. interface Numeric { T zero(); T add(T a, T b); } static T sum(Numeric n, T[] v) { T summer = n.zero(); for (int k = 0; k

Honestly I have no idea what's going on with this code.

Where is `zero()` defined? Why does a `Numeric` have a function to `add` two numbers? Shouldn't you add a single number to a numeric? What is the relationship between `` and `Numeric`? I thought `T` was a `Numeric`?

Edit: Upon closer inspection, I kind of get what's going on. But it's really cryptic for something that should be simple to express.

Re: Go generics are not bad

#86

Post by aw1621107 »

enw wrote: post #85
throwaway234232 wrote: post #49

I think in Java, you would need to do a type-class approach. interface Numeric { T zero(); T add(T a, T b); } static T sum(Numeric n, T[] v) { T summer = n.zero(); for (int k = 0; k

Honestly I have no idea what's going on with this code. Where is `zero()` defined? Why does a `Numeric` have a function to `add` two numbers? Shouldn't you add a single number to a numeric? What is the relationship between ` ` and `Numeric `? I thought `T` was a `Numeric`? Edit: Upon closer inspection, I kind of get what's going on. But it's really cryptic for something that should be simple to express.

> Where is `zero()` defined?

It's defined by whatever implements the interface.

> Why does a `Numeric` have a function to `add` two numbers?

Because Java doesn't have user-defined operator overloading, so if you want to add stuff in a generic fashion you can't rely on `+`.

> Shouldn't you add a single number to a numeric? What is the relationship between `` and `Numeric`? I thought `T` was a `Numeric`?

`Numeric` doesn't contain data, it just defines operations on numbers. So `Numeric` would define operations on `int`s, `Numeric` would define operations on `BigInteger`s, etc.

Re: Go generics are not bad

#87

Post by danielscrubs »

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 great language because they always take the easy way (makes more business sense, see Dart). Academia on the other hand will make great languages that never reaches critical mass.

Re: Go generics are not bad

#88

Post by maxbond »

nine_k wrote: post #71
Avlin67 wrote: post #52

Earlier quoted context omitted.

also in .Net but then you enter a generic hell and you start thinking vanilla es6 is better

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 can be safely ignored anywhere it isn't used.

When this component you're updating is highly connected to other parts of your code, perhaps add another generic parameter to it, it completely explodes and you have to jump all around your codebase adding generics.

The kicker is that you may be updating components which are themselves generic and highly connected, setting off secondary explosions. Pretty soon you're throwing that codebase out, starting over, and swearing to yourself that you'll never touch generics again.

My advice is to assume generics are a premature abstraction until you've exhausted what you can do with more concrete approaches.

Re: Go generics are not bad

#89

Post by VirusNewbie »

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”

that's not a function (in the pedantic sense).

technically a partial function, or you could say that every function is really of the type A -> Exception \/ A

Re: Go generics are not bad

#90

Post by rowanG077 »

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…

This is not the case with traits/type class approach seen in Rust/Haskell.
Post reply on HN