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

341–350 of 439 posts

Re: Proposal: Go should have generics

#341

Post by imtringued »

Scarbutt wrote: post #328
zellyn wrote: post #213

Earlier quoted context omitted.

I simply do not believe this. I believe it is thriving because it was well-designed, by extremely influential individuals, and the early library work was stellar. Also, several other experienced and influential programmers tried it, and expressed something along the lines of "programming is fun again!" Inside Google, the two main programming languages are C++ and Java, not Go (at least when I left, in September). The…

Redhat or Apple are not "Joe the dev" though

Java Joe works at Readhat though :P

Re: Proposal: Go should have generics

#342

Post by ball_of_lint »

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

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

Wouldn't that end up being essentially equivalent to adding generics to go?

Re: Proposal: Go should have generics

#343

Post by duaneb »

idobai wrote: post #123
duaneb wrote: post #18

Earlier quoted context omitted.

Generics are not "all the things". Last i checked there was still no object inheritance (in a subtype sense for interface implementations), no operator overloading, no bytecode/vm/jit, no inline asm, no macros, no pluggable gc, no call/cc, no (idiomatic) exceptions, no currying, no weak typing or implicit conversions, no way of enforcing referential transparency, no STM, no laziness, no assertions, no contracts, no u…

> EDIT: of course this is good; such a language would be beyond nightmarish. By which i mean c++ or scala. Then go and compare the same code in go and Scala and see which is more "nightmarish". You see Scala as a complex language because you need to learn something before you use it while go is almost the opposite - you may get it in an afternoon and create repetitive, boilerplatish and unmaintanable mess.

> You see Scala as a complex language because you need to learn something before you use it

No, I see Scala as a complex language because—much like C++—each library uses its own curious dialect. There is no community consensus on the balance between the object-oriented and functional. It's a mess, albeit a mess I'd prefer over most other languages. But dealing with implicits, language changes between versions, and "default" trait implementations (e.g. `val foo = Set()` is a simple example) makes me consider the language nightmarish.

Re: Proposal: Go should have generics

#344

Post by serge2k »

saturn_vk wrote: post #283
parenthephobia wrote: post #216

Earlier quoted context omitted.

I don't think we will. The Go community doesn't hate protocolbuffers, but it does tend to think that generics are evil and shouldn't exist. I'm certain that generic generators will be shunned by the community at large, due to solving a problem they don't believe needs solving. Without the network effect to build up a user and developer-based, they'll languish in obscurity. I sure would like to be wrong, though!

I haven't seen any indication that the community hates the idea of having generics. The contrary seems to be the case.

Seems like they talk a lot about how it's a problem but don't put the effort into solving it.

In other words, they aren't interested in getting generics. Not really.

Re: Proposal: Go should have generics

#345

Post by sythe2o0 »

nostrademons wrote: post #322
sythe2o0 wrote: post #302

Earlier quoted context omitted.

nil in Go doesn't work that way. Most types cannot be nil.

Interesting, because (reading up on this) value types can not be nil. How often does typical Go code use values vs. interfaces or pointers? It seems like the situation is pretty similar to modern C++, which also does not allow null for value or reference types (only pointers) and encourages value-based programming. Nil is still a problem there, but less of one than in, say, Java, where everything is a reference.

In my own experience, nil basically only shows up when I've failed to initialize something (like forgetting to loop over and make each channel in an array of channels), or when returning a nil error to indicate a function succeeded. I've never run into other interfaces being nil, but I also haven't worked with reflection and have relatively little Go experience (~6 months).

The code that I've written regularly uses interfaces and pointers, but I'd guess 80% works directly with values.

Re: Proposal: Go should have generics

#346

Post by imtringued »

catfest wrote: post #72
omginternets wrote: post #70

Earlier quoted context omitted.

>you get the language simplicity And the most complex toolchain imaginable. This is what turns me off to Java, personally, but I think my case is fairly representative.

The toolchain is what's so awesome about Java - moving to a language like Go means you lose so much, it's painful.

Which is why it's mostly developers that previously used dynamic languages. They didn't have sophisticated IDEs.

Re: Proposal: Go should have generics

#347

Post by NateDad »

pklausler wrote: post #340
NateDad wrote: post #335

Earlier quoted context omitted.

> >Do we have 67 implementations of sort.Interface? > Hahaha. This has to be satire right? Nope. /home/nate/src/github.com/juju/juju$ grep -r ") Less(" . | wc -l 67 (granted, 10 are under the .git directory, so I guess 57) But in any other language, we'd still have the same 57 definitions of how to sort a type.... we'd just have 3 fewer lines of boilerplate for each of those (which live off in the bottom of a file so…

> But in any other language, we'd still have the same 57 definitions of how to sort a type... That claim turns out to not be the case.

Aside from trivial types, like strings or integers, how does the language know how to sort a list of values, if you don't tell it how to?

Translate this into whatever language you like:

    Machine {
        Name string
        OS  string
        RAM int
    }
You have 3 places that want to sort a list of machines, one by name, one by OS, and one by RAM. You're telling me there's a language that can do that without having to write some kind of code like this for each?

   sort(machines, key: Name)
I don't understand how that's possible, but I welcome your explanation.

Re: Proposal: Go should have generics

#348

Post by howeman »

akavi wrote: post #336
NateDad wrote: post #309

Earlier quoted context omitted.

Actually readability at the point of use is very reader-friendly: machines := db.GetAllMachines() sort.Sort(byName(machines)) For those not familiar with Go, the sort.Sort line is converting the list of machines into a type that matches the interface that sort.Sort expects. The list of machines is sorted in-place The only part that can be subtly changed is the Less function, which determines the sort order. And as I'…

What does the implementation of `byName` look like? I'm not sure I understand what its return type would be.

Either sort.Interface or a type that implements sort.Interface

Re: Proposal: Go should have generics

#349

Post by NateDad »

akavi wrote: post #336
NateDad wrote: post #309

Earlier quoted context omitted.

Actually readability at the point of use is very reader-friendly: machines := db.GetAllMachines() sort.Sort(byName(machines)) For those not familiar with Go, the sort.Sort line is converting the list of machines into a type that matches the interface that sort.Sort expects. The list of machines is sorted in-place The only part that can be subtly changed is the Less function, which determines the sort order. And as I'…

What does the implementation of `byName` look like? I'm not sure I understand what its return type would be.

byName is a type. It's a named type based (likely) on a slice of machines. The byName type implements the functions necessary to support the interface that the sort.Sort function requires:

    type byName []Machine
    
    func (b byName) Len() int { return len(b) }
    func (b byName) Swap(i, j int) { b[j], b[i] = b[i], [b[j] }
    func (b byName) Less(i, j int) { return b[i].Name
sort.Sort takes an interface type that has the methods Len, Swap, and Less, as defined in the signatures above, and uses them in a sorting algorithm which sorts the values in-place.

Re: Proposal: Go should have generics

#350

Post by MustardTiger »

agentgt wrote: post #230

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…

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

Yes, I find compilation speed to be one of the most important things. But it is not a selling point for go. The go compiler is not very fast, and speed is not an acceptable excuse for a lack of parametric polymorphism. Ocaml has not just parametric polymorphism, but many other basic type system features. And yet ocamlopt is both 5-10 times faster than the go compiler, and still produces faster binaries.

Post reply on HN