Live data from Hacker News

Proposal: Go should have generics

github.com

71–80 of 439 posts

Re: Proposal: Go should have generics

#71

If they accept generics, then there is an implication that the language design isn't infallible as a result of being written by Rob Pike, and then the whole house of cards falls down as people start clamouring for things like real exceptions.

Yeah they haven't done it yet, and might still never do it, to save face. What could have been a simple 1.0 missing feature has been politicized into Go's defining feature/mistake.

There is nothing political about it, and speaking as someone on the inside it is simply ridiculous to think of it that way. What these real proposals show is that a lot of sincere effort has been spent by members of the core team writing, reviewing, and debating generics proposals over a span of multiple years. Ian only recently felt comfortable releasing them publicly, and so here they are.

Re: Proposal: Go should have generics

#72
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 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.

Re: Proposal: Go should have generics

#73
post #50

Earlier quoted context omitted.

Single small binaries are easy with go, very hard with java.

If you have the money, there are lots of commercial JVMs with compilers to native code. There are quite a few open source ones, but they aren't as stable. As always, Language != Implementation.

Could you recommend any that you have had experience with?

Re: Proposal: Go should have generics

#74
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.

That comes with a big memory cost, though. Also huge startup time, so not suitable for command line tools.

I don't think startup time is an issue, and memory is definitely manageable - check out LMAX Disruptor (https://lmax-exchange.github.io/disruptor/)

Re: Proposal: Go should have generics

#75
post #64

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…

It's really not bad in practice. I've measured the amount of compilation time that generic instantiations take up and it's always been pretty low. Something like 20% (it's been a while, so take with a grain of salt), and that's with a naive implementation that doesn't try to optimize polymorphic code or perform ahead of time mergefunc. 20% is well within the project's demonstrated tolerance for compiler performance regressions from version to version. And you can do better with relatively simple optimizations. Generic compilation has been well-studied for decades; there are no unsolved problems here.

I would heavily advise against trying to do better than monomorphization with intensional type analysis (i.e. doing size/alignment calculations at runtime). We tried that and it was a nightmare. It didn't even save on compilation time in practice because of high constant factor overhead, IIRC.

Monomorphization is one of those things, like typechecking in ML, where the worst-case asymptotic time bounds look terrible on paper, but in practice it works out fine.

People point to C++ compilation times as a negative counterexample, but most of the compilation time here is in the parsing and typechecking, which a strongly typed generics implementation will dodge.

Re: Proposal: Go should have generics

#76
post #23
post #12

Earlier quoted context omitted.

This. For better and for worse, Go was designed for "simplicity", and generics are anything but simple. I'd be very, very surprised if Go thinks about generics in earnest anytime soon. I don't say this in anyway to eulogize Go: In some ways, Go is pathetically unexpressive. That said, it currently fills that gap for writing middleware between C sacrificing too much developer productivity and Perl/Python/Ruby/PHP sacr…

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.

Language simplicity? I disagree, Java is only agreable if you're comfortable with (1) being forced to work in an OOP-only environment and (2) using the JVM. And while you can argue for the upsides of both of these (which I believe are few and far between) they certainly add a great deal of clunky complexity, which many programmers are fleeing to Golang to avoid.

Re: Proposal: Go should have generics

#77

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.

Re: Proposal: Go should have generics

#78
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 And the most complex toolchain imaginable. This is what turns me off to Java, personally, but I think my case is fairly representative.

Nobody forces you to use a complex toolchain for Java. You can use javac and ed if you like. But Java is sufficiently simple and sufficiently popular for pretty awesome tooling to be available. Refactoring Java code is a breeze because your IDE understands the code perfectly.

Re: Proposal: Go should have generics

#79
post #50

Earlier quoted context omitted.

Single small binaries are easy with go, very hard with java.

If you have the money, there are lots of commercial JVMs with compilers to native code. There are quite a few open source ones, but they aren't as stable. As always, Language != Implementation.

Agreed, but remember that

  Language == Thought-space >= Implementation,
so you want to maximize your language's expressiveness.

Re: Proposal: Go should have generics

#80
post #23
post #12

Earlier quoted context omitted.

This. For better and for worse, Go was designed for "simplicity", and generics are anything but simple. I'd be very, very surprised if Go thinks about generics in earnest anytime soon. I don't say this in anyway to eulogize Go: In some ways, Go is pathetically unexpressive. That said, it currently fills that gap for writing middleware between C sacrificing too much developer productivity and Perl/Python/Ruby/PHP sacr…

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.

Post reply on HN