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

131–140 of 305 posts

Re: Go generics are not bad

#131

Post by hardware2win »

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…

Please show code then

I dont remember misusing C# generics even once and I struggle to see example of such a case

Re: Go generics are not bad

#132

Post by tsimionescu »

kaba0 wrote: post #117
zamalek wrote: post #24

Earlier quoted context omitted.

> Java can't do this because the primitive types are not objects. So this excuses the awful Java genetic how? "It smells like sewage in the basement because the basement is full of sewage." In addition, generics over primitive/stack/value types (including mathematical operators) is working just fine in the latest iteration of C#.

Some more context would be appreciated on why you think that Java generics are awful?

The context is what was said above: Java generics can't abstract over primitive types, they only work for objects. That is awful, and it is important, because this one limitation is the only thing that makes the implementation of generics in Java possible and simple.

If generics had had to actually support ArrayList, they would have required significant changes to how ArrayList is stored in memory, and to how a lot functions which work with generic types are actually compiled. Instead, Java has the easy path in the implementation: since everything only works with reference types, there's no need for multiple copies of a function to work with different types.

Of course, this means that sum(new Integer[1000000]) is going to be orders of magnitude slower than sumInts(new int[1000000]).

Re: Go generics are not bad

#133

Post by tsimionescu »

Beltalowda wrote: post #72
google234123 wrote: post #59

Earlier quoted context omitted.

Not sure how 3.5 follows.

And 1. is demonstrably false as has been stated a million times already.

They demonstrably decided generics are not needed for Go at release, or for the following 5+ years, I don't know how that could be seen as false. If they had thought generics are required for Go, they wouldn't have released the language before they had them.

What is often claimed instead, and is indeed false, is that they believed generics should not exist in Go. This is a position that many Go proponents take, but the designers of the language never did.

Re: Go generics are not bad

#134

Post by kaba0 »

tsimionescu wrote: post #132
kaba0 wrote: post #117

Earlier quoted context omitted.

Some more context would be appreciated on why you think that Java generics are awful?

The context is what was said above: Java generics can't abstract over primitive types, they only work for objects. That is awful, and it is important, because this one limitation is the only thing that makes the implementation of generics in Java possible and simple. If generics had had to actually support ArrayList , they would have required significant changes to how ArrayList is stored in memory, and to how a lot…

It is unfortunate, but that was the only way Generics could ship at the time in a backwards compatible way. But I don’t think it is fair to call it awful, especially knowing the context. Also, when it does show up as a performance bottleneck, it is trivial to fix.

Re: Go generics are not bad

#135

Post by mcronce »

throwaway894345 wrote: post #105
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’m pretty sure Go’s maintainers were aiming for “mere” practical success, as opposed to some theoretical success that only academic languages succeed at.

What's the definition of "success" here? Popularity?

Re: Go generics are not bad

#136

Post by hgomersall »

maxbond wrote: post #91
rowanG077 wrote: post #90

Earlier quoted context omitted.

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

I'm afraid that it most certainly is, as Rust is the only language I have ever used generics in, and I had this problem. Lifetimes suffer from the exact same problem as well, since they're really an exotic form of generic. That said, I will readily admit that it was a lack of skill on my part. From talking to people in the Rust community though, I gather this isn't an uncommon experience.

They're not viral in rust - you can always replace the generic with a concrete type in super types.

Re: Go generics are not bad

#137

Post by mcronce »

throwaway894345 wrote: post #84
wahern wrote: post #64

Earlier quoted context omitted.

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.

Go's issues are mostly not performance related, so more monomorphization will really not solve a significant portion of them.

Re: Go generics are not bad

#138

Post by e12e »

nicoburns wrote: post #7
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…

> 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. B…

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

I'm not sure "sum over an array of int" is a great "simple" example - how do you guarantee that the result can fit in an int?

This is (one reason) why Julia implemented a full, scheme-style, numeric tower right in the core language.

Sure there are some examples where you can sum N Mbit numbers into an Mbit number, and either want overflow, or is somehow "confident" things will fit. But in general it's just lazy "no one will ever have such a large shopping cart"-design...

Re: Go generics are not bad

#139

Post by e12e »

dataangel wrote: post #125
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…

Writing a generic function to sum an array of any numbers type is trivial in C++. There's no 4 day research period, even if you're new to templates. template T sum(T* x, size_t size) { T acc = 0; for(size_t i = 0; i

Isn't acc and the xs same width here? So you risk overflow?

Re: Go generics are not bad

#140

Post by grumpyprole »

truffdog wrote: post #108
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…

Ian Lance Taylor worked on generics for like a decade, and the final design was heavily based on the Featherweight Go paper, which had formal proofs of the design given a simplified version of the go language. This is a very odd complaint around this feature.

Yes retrofitting is hard. However, "Generics", also known as parametric polymorphism is well understood and goes back to Milners ML from the 70s.
Post reply on HN