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.
Proposal: Go should have generics
71–80 of 439 posts
Re: Proposal: Go should have generics
#72Earlier 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.
Re: Proposal: Go should have generics
#73Earlier 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.
Re: Proposal: Go should have generics
#74Earlier 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.
Re: Proposal: Go should have generics
#75Earlier 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…
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
#76Earlier 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.
Re: Proposal: Go should have generics
#77I 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…
Re: Proposal: Go should have generics
#78Earlier 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.
Re: Proposal: Go should have generics
#79Earlier 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.
Language == Thought-space >= Implementation,
so you want to maximize your language's expressiveness.Re: Proposal: Go should have generics
#80Earlier 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.
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.