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

Proposal: Go should have generics

github.com

Post reply on HN
Print view View original

221–230 of 439 posts

Re: Proposal: Go should have generics

#221

Post by louthy »

thegenius2000 wrote: post #165
tazjin wrote: post #125

Earlier quoted context omitted.

This is what people mean when they say that Go has disregarded everything we learned in the programming language community in the last decades. Sure, some people are productive in it and that's fine - but for those of us who have worked in better languages taking the step down is unattractive.

I'll grant that Go is lacking in generics, but IMHO, the opposite is true. Go is thriving because although not perfect, it is one of the few languages which seems to have learned lessons from the failings of C++, Java; and from the successes of the more dynamic/scripting languages (team Python, Ruby etc.). Go isn't a step down, it's a step backwards from the edge of the cliff.

That's just rhetoric. What does it mean? What lessons have been learned? What is it about generics that makes them the 'edge of the cliff'? Personally I couldn't live without generics, and would never choose a language that doesn't have them; otherwise you end up doing cartwheels with untyped references and reflection to try and write reusable code (as you see above). The idea that generics adds complexity is nonsense. It might add complexity to the compiler, but that's about it. For the end user and the compiled code it's easier and faster respectively.

Re: Proposal: Go should have generics

#222

Post by parenthephobia »

brightball wrote: post #192
mattlondon wrote: post #68

I can feel the pain on the Sort issue. I've personally found sorting annoying in Go - I had a bunch of structs representing data entities from a database that all had the same field and I wanted to be able to sort them by this field. Seemed like a LOT of work (basically implementing the same sort that was 99% identical for every struct) or use weird reflection-workarounds to get this to happen. In Java I would not ev…

Couldn't you create a common interface that you could use for the sort?

No. There is no interface that "sortable" things implement, other than the empty interface, and no neat way to define one.

Numbers and strings support You could do

    type Comparable interface {
      Compare (x Comparable) int // -> -1, 0, 1
    }

    func Sort (x []Comparable): []Comparable {
      /// ...
    }
And whilst this Sort could work, how do you call it? []int isn't []Comparable, and can't be converted to one: you have to make a new array. Then, when you want an array of ints on the other end, you have to convert it back, which now involves run-time type assertions.

Even an array of something that implements Comparable isn't compatible - it can't be, because Go doesn't know Sort won't take Bar[] and put a Foo in it, if Foo and Bar both implement Comparable.

And, whilst you can define Compare for int, the other argument will be a Comparable, not a int, so you'll have to have a run-time type assertion for each comparison.

Conversely you might try

    func Sort (x []interface{}, f func(interface{}, interface{})int) []interface{} {
      /// ...
    }
You still can't sort []int, and your comparison function can't know it's receiving int, so it will have to type-assert both arguments at each comparison.

Re: Proposal: Go should have generics

#223

Post by tombert »

Isn't a huge issue with generics the compilation time?

Much as I love Haskell, I'm not going to sit here and tell you that a big program compiles quickly.

That might be an individual issue with Haskell, but regardless, isn't type-inference kind of expensive in compilation-land? And wouldn't that kind of kill one of the big features of Go?

Re: Proposal: Go should have generics

#224

Post by bmaupin »

sievebrain wrote: post #195
fosk wrote: post #73

Earlier quoted context omitted.

Could you recommend any that you have had experience with?

RoboVM is one that compiles AOT ARM binaries, it's intended for the iPhone but it runs on MacOS too. Avian is a JIT compiling JVM but one which is much smaller than HotSpot. It has a mode where it statically links your JAR into the binary itself, so you get a single self contained executable. With ProGuard and other optimisations like LZMA compression built in, such binaries can be remarkably small. Try their example…

RoboVM can also compile to OS X and Linux:

Usually this means iOS and the ARM processor type but RoboVM is also capable of generating code for Mac OS X and Linux running on x86 CPUs. [0]

There are several forks of the latest open-source version of RoboVM. This one in particular is targeting desktop/server usage:

https://github.com/ashleyj/aura

See also: https://news.ycombinator.com/item?id=7579737

[0] http://docs.robovm.com/advanced-topics/compilation.html

Re: Proposal: Go should have generics

#225

Post by kdogt »

andrewfromx wrote: post #203

can I tell u the BEST thing about golang? Strings cannot be nil! It's amazing. They are always "" or you know, "something" so you never have to test for if s == nil || s == "" or in ruby s.blank? to cover both cases. that is all.

In sane languages (see: Haskell, Swift, Rust), this is the case for all types. Having non-nullability only be the case for one type might be worse than having everything nullable, actually.

Re: Proposal: Go should have generics

#226

Post by jhalderman »

junke wrote: post #211
enneff wrote: post #188

Earlier quoted context omitted.

This thread is about sort interface implementations. Their general form will never change, and the only specifics unique to any given copy are those specific to their type. It is obvious to any Go programmer what can and cannot be changed in this situation.

The thread was more about mattlondon's problem with sorting according to the same key in different structs. I used of modified version of this example[0] to illustrate what I think is his problem[1]: you can sort circles and planet by radius, and probably many other things in the original case, but you are required to copy-paste the definitions. I can understand that instantiating templates by hand is not so bad. But…

Why not write an interface for getting the radius and a radius sorter for sorting on that interface? I made a modified version of your code to illustrate.

https://play.golang.org/p/Ya7tUhDnO2

*edited a typo

Re: Proposal: Go should have generics

#227

Post by parenthephobia »

enneff wrote: post #85
xiaq wrote: post #77

Earlier quoted context omitted.

Write a code generator. That's the best solution at this moment.

Or, y'know, just copy and paste the trivial code. It should take all of 30 seconds. Not saying that it's pretty, but it's quick and easy.

What if I'd done that 20 times around my code-base and then later I discover there's an off-by-one error in the original code that's maybe been inherited into all 20 copies?

If I could actually reuse code properly I'd only have to fix it once.

Without effective code reuse, I have to hunt down the copies, each of which may have slight modifications to make them better fit their use case (and might be hard to grep for as a result), figure out whether or not the bug exists in that copy (and whether it can actually be triggered), and fix it there.

The description of inheritance in http://typicalprogrammer.com/abject-oriented/ seems relevant here. (Edit: Derp, junke got there way before me!)

Re: Proposal: Go should have generics

#228

Post by wcummings »

tombert wrote: post #223

Isn't a huge issue with generics the compilation time? Much as I love Haskell, I'm not going to sit here and tell you that a big program compiles quickly. That might be an individual issue with Haskell, but regardless, isn't type-inference kind of expensive in compilation-land? And wouldn't that kind of kill one of the big features of Go?

Who said anything about type inference?

Re: Proposal: Go should have generics

#229

Post by s_kilk »

lucozade wrote: post #209
reycharles wrote: post #92

Earlier quoted context omitted.

Rob Pike's repository 'filter'[0] contains implementations of map ("Apply"), filter ("Choose", I believe), and fold/reduce ("Reduce"). The code is an ugly mess, and the implementation shows that he probably hasn't used any of these standard functions in other languages (see the weird permutations of 'filter' in apply.go, or my patch for his fold/reduce implementation[1]). The README is also quite arrogant, IMO. > I w…

I quite like the logical progression though: + People keep telling me we should be able to implement a map function in go. + I implemented a map function in go. + The map function was ugly, slow, unsafe and generally an abomination. Conclusion? You don't need a map function in go. You may not agree but you have to admire his dedication to the One True Way whatever is put in his way. Even if it's him that's erecting p…

The mental gymnastics required to adhere to the One True Way are certainly impressive.

Re: Proposal: Go should have generics

#230

Post by agentgt »

I have some biased doubts (come from the JVM world) about needing really fast compiling and is often cited as the reason Go does things the way it does (or is).

Is binary dependency management just not an option ever?

I have a friend that works for Google and supposedly they have a proprietary build infrastructure that will offload the building of C++ code into a cluster. I sort of wish Google open sourced that as I believe it basically does some form of binary dependency management.

Yes I know Go like C++ can target lots of platform (and thus needs many binaries built) but an organization only needs the major ones. And yes I know the language statically compiles to a single binary but that doesn't mean things can't be precompiled.

Go these days seems to be mainly used for microservices or small utilities and thus you don't need and should not have a gigantic code base for such things. I can understand monolithic UI apps having large code bases but this is clearly not what Go is being used for these days.

There are many other languages that compile to native that seem to compile fairly fast (OCaml and Rust from my experience but I don't have huge code bases).

Is compilation speed really an issue given the use cases for Go?

Post reply on HN