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

141–150 of 439 posts

Re: Proposal: Go should have generics

#141

Post by fauigerzigerk »

mcculley wrote: post #133
fauigerzigerk wrote: post #82

Earlier quoted context omitted.

Memory usage and as a consequence of that excessive GC pauses. I'm not looking at any JVM language again before they introduce value types in a couple of years (maybe).

I build soft real time simulation systems in Java. GC pauses haven't been a problem since 1.2 was released around 2000. Memory usage isn't a concern either for big applications, as there's not a lot of overhead in the runtime. There is the fact that one can't embed value types directly in objects, but I don't find that a problem in practice.

Then your experience is very different from mine and that of many other people who resort to all sorts of off-heap solutions and distributing stuff across multiple VMs. I guess it depends a lot on the specific use case.

Re: Proposal: Go should have generics

#142

Post by Sean1708 »

reycharles wrote: post #92
bigdubs wrote: post #7

After watching Rob Pike's Go Proverbs talk I am pretty convinced generics, as much as some would want it, will never happen. He proselytizes "just copy a little code here and there" quite clearly, which is at odds with the complexity that generics would add.

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…

    // goodFunc verifies that the function satisfies the signature, represented as a slice of types.
    // The last type is the single result type; the others are the input types.
    // A final type of nil means any result type is accepted.
    func goodFunc(fn reflect.Value, types ...reflect.Type) bool
Dear god, why?!

Re: Proposal: Go should have generics

#143

Post by iopq »

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.

commit c270f19d456e862aeb559098fa32d36fbc5329a0 Date: Wed Apr 13 04:57:46 2016 -0700

    fixing level selection again
commit dae018e4f76db0e9da810b4560d6c8e1c7029048 Date: Mon Apr 11 07:06:47 2016 -0700

    fixing level selection for hint case
commit a754bcd0d09ab1e357ae28c8f06baf65d879878f Date: Sat Apr 9 02:33:14 2016 -0700

    forgot to fix the level selection in the move case

Re: Proposal: Go should have generics

#144

Post by trhway »

jcoffland wrote: post #120
trhway wrote: post #105

Earlier quoted context omitted.

mental exercise - replace C++ with "generics" and git/kernel/etc with "Go" here http://harmful.cat-v.org/software/c++/linus

Linus is clearly throwing his weight around here. If anyone else were to act this way and use such language we would all call him or her an asshole. Besides his main point is that C++ is not great for low level code. I don't see how this applies here.

we see things differently. In my view Linus is speaking free here. Many others refrain from speaking free and truthfully for fear of being called an asshole.

I see different main point. In my view Linus narrows the domain of his speech to system-level (not low-level!) code just out of basic intellectual honesty which implies to speak with authority only where your experience and knowledge are.

Re: Proposal: Go should have generics

#145

Post by TazeTSchnitzel »

isuckatcoding wrote: post #98

This makes me wonder if this has happened before in another language. I can totally imagine 10 years ago someone saying "oh we'll never need that in PHP" and voila 10 years later you've now got feature X in PHP. Any of you wise old timers want to share such examples? Does history keep repeating itself with these sorts of things?

PHP now has optional strict type checking for non-complex types, since last year. That was a huge change: https://ajf.me/talks/2015-10-03-better-late-than-never-scala...

Re: Proposal: Go should have generics

#146

Post by rdsubhas »

Animats wrote: post #49

Generics as a language retrofit tend to be ugly. See C++. I was at one time plugging for parameterized types. Go already has parameterized types; "map" and "chan" are parameterized types. You write "make(chan int)" and "make(map[string] int)". You just can't define new parameterized types; "map" and "chan" are all you get. With parameterized types, you could create more generic data structures; if you needed a generi…

Depends on the implementation. See Java.

Re: Proposal: Go should have generics

#147

Post by barrkel »

agentS wrote: post #64
pcwalton wrote: post #43

Earlier quoted context omitted.

CLR-style just-in-time monomorphization is plenty performant: in fact, it's just about ideal. It's also not that difficult when you have a JIT when compared to the complexity you need for speculative optimizations of hot spots anyway. In any case, the .NET approach isn't an option for AOT compilers like those of Go. For Go, the only reasonable option is ahead of time monomorphization, which really isn't that bad.

Monomorphization is not a reasonable option, in my opinion. It forces the compiler to accept some truly awful running times for pathological cases. Atleast quadratic, probably exponential. For languages that have reflection or pointer maps for GC or debug information for types, it can force large blowups in space as well. Go has all three of these. The implementation would likely require runtime code-generation (or a…

Bear in mind that .NET will use a shared instantiation when the generic arguments are normal reference types; a hidden parameter is required for static methods under this scheme, to pass the concrete type info. Monomorphization is only required when the vector of generic arguments has a distinct permutation of reference types vs value types.

This gives you the best of both worlds: memory efficient generics for the majority of instantiations, and compute efficient generics for the types most likely to benefit (like primitives).

Re: Proposal: Go should have generics

#148

Post by masklinn »

reycharles wrote: post #80
catfest wrote: post #23

Earlier quoted context omitted.

I don't see why you'd choose Go instead of a JVM language like Java, you get the language simplicity (plus features like Generics) and the performance upside too.

> you get the language simplicity I remember the Go language specification to be about as long as the table of contents for the Java language specification. On the other hand, Brainfuck is an extremely simple language, too.

> I remember the Go language specification to be about as long as the table of contents for the Java language specification.

I'm not sure where you got that from. On my browser and screen, the JLS8 TOC[0] is 16 pages high which brings me about 20% into the Go language spec[1].

But then again that's a completely inane appeal to emotions: because it's a specification for cross-platform and cross-implementation compatibility (not a user-targeted documentation):

* the JLS is exactingly precise, the JLS's "lexical structure" section is about 3 times longer than GoSpec's "Lexical Elements", the JLS's "Execution" section is about 6 times longer than GoSpec's "Program initialization and execution"

* the JLS contains entire sections which don't get a mention in GoSpec, like binary compatibility concern, or the language's entire execution model (calling a function gets a page in gospec, it gets 20+ in the JLS) and its multithreaded memory model

The JLS is longer because its goal is that you be able to reimplement a Java compiler and runtime just from it, it's Java's entire rulebook.

Go's language spec is a much fuzzier document targeted towards language users — much like e.g. Python's language reference — there is no way you can write a clean-slate implementation just from the language spec.

[0] https://docs.oracle.com/javase/specs/jls/se8/html/index.html

[1] https://golang.org/ref/spec

Re: Proposal: Go should have generics

#150

Post by sievebrain »

reycharles wrote: post #92
bigdubs wrote: post #7

After watching Rob Pike's Go Proverbs talk I am pretty convinced generics, as much as some would want it, will never happen. He proselytizes "just copy a little code here and there" quite clearly, which is at odds with the complexity that generics would add.

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…

So Google's primary language offering is designed by a guy who thinks Map/Reduce is just a weird way of writing for loops.

Tremendous. The amount of irony in that could fill a steel furnace for a year.

Post reply on HN