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

Go 1.5 Release Notes

tip.golang.org

Post reply on HN
Print view View original

31–40 of 66 posts

Re: Go 1.5 Release Notes

#31

Post by crawshaw »

bsaul wrote: post #28
arihant wrote: post #23

Earlier quoted context omitted.

Russ Cox said this year that generics aren't left out because of political reasons or design choice. They are left out because of technical constraints which are: - Generics in current form won't work across the board with all parts of Go. - Generics of form that will work for Go across the board are not technically trivial. Honestly, I appreciate Go's philosophy of not implementing until fully understood and accepte…

Purely out of curiosity, do you know of any talk that would explain in detail why things like swift's protocol extension can be implemented in conjunction with generics, and go interfaces can't ? From the outside, the two features (swift's protocol with extensions and go interfaces) seem a bit close, so that made me wonder. I didn't have the time to think too much in detail about it, so i'm just wondering if anybody…

It can be done, the question is can it be done in a way that fits with everything else in Go?

There are technical drawbacks in the implementation of parametric polymorphism that don't suit Go's design goals: http://research.swtch.com/generic.

Re: Go 1.5 Release Notes

#32

Post by coldtea »

arihant wrote: post #23
snuxoll wrote: post #22

Earlier quoted context omitted.

And still no generics. Honestly, at this point I just wish they'd add a 'void' alias for 'interface {}' so at least non-typesafe code was only as ugly as the equivalent C -_-

Russ Cox said this year that generics aren't left out because of political reasons or design choice. They are left out because of technical constraints which are: - Generics in current form won't work across the board with all parts of Go. - Generics of form that will work for Go across the board are not technically trivial. Honestly, I appreciate Go's philosophy of not implementing until fully understood and accepte…

>Russ Cox said this year that generics aren't left out because of political reasons or design choice.

They've been saying that from the begining. There are no real technical constraints, it's been done in all kinds of languages and it has been a well understood feature for 2+ decades. They just don't want to do the compromises needed, while letting the developers continue to deal with all of them...

See also pcwalton's (of Rust fame) comment below.

Re: Go 1.5 Release Notes

#33

Post by coldtea »

crawshaw wrote: post #31
bsaul wrote: post #28

Earlier quoted context omitted.

Purely out of curiosity, do you know of any talk that would explain in detail why things like swift's protocol extension can be implemented in conjunction with generics, and go interfaces can't ? From the outside, the two features (swift's protocol with extensions and go interfaces) seem a bit close, so that made me wonder. I didn't have the time to think too much in detail about it, so i'm just wondering if anybody…

It can be done, the question is can it be done in a way that fits with everything else in Go? There are technical drawbacks in the implementation of parametric polymorphism that don't suit Go's design goals: http://research.swtch.com/generic .

All of the supposed reasons given in that post have been answered to death by multiple people (including PL experts), and none holds to much scrutiny.

"We just can't be bothered" or "we don't think they're much good, and we don't have a need for them" would be a much more realistic answer.

Re: Go 1.5 Release Notes

#34

Post by theseoafs »

coldtea wrote: post #30
_ph_ wrote: post #14

Earlier quoted context omitted.

They automatically translated C code to Go code. The objective was to produce correct Go code, speed was not an immediate concern - the auto-translated code mostly is very bad Go code, speed wise. Optimizing the Go code base of the compiler is the next step, planned to happen in subsequent releases.

> the auto-translated code mostly is very bad Go code, speed wise. Is it? It might not be particularly optimized, but why would that ("very bad speed wise") be the case?

Generally, compilers aren't very good at compiling code that isn't idiomatic for the language. This is by design, since compiler writers try to make idiomatic, common code fast first and foremost.

Re: Go 1.5 Release Notes

#35

Post by melling »

snuxoll wrote: post #22
arihant wrote: post #12

tl;dr - No change in language, one minor consistency oversight fixed. Big changes on implementation, including compiler being bootstrapped.

And still no generics. Honestly, at this point I just wish they'd add a 'void' alias for 'interface {}' so at least non-typesafe code was only as ugly as the equivalent C -_-

Were you surprised. They've said generics won't appear before 2.0, and they may never appear.

We have this discussion after every minor release. 1.6 will be released in December. See you then.

Re: Go 1.5 Release Notes

#36

Post by crawshaw »

coldtea wrote: post #33
crawshaw wrote: post #31

Earlier quoted context omitted.

It can be done, the question is can it be done in a way that fits with everything else in Go? There are technical drawbacks in the implementation of parametric polymorphism that don't suit Go's design goals: http://research.swtch.com/generic .

All of the supposed reasons given in that post have been answered to death by multiple people (including PL experts), and none holds to much scrutiny. "We just can't be bothered" or "we don't think they're much good, and we don't have a need for them" would be a much more realistic answer.

I haven't seen any rejoinders to that document that contradict the fact that you pay for parametric polymorphism with either slower compilation or slower runtime.

Go isn't interested in either being slow. Any generics solution has to have fast runtime, because they need to replace the builtin parametric slices and maps. And the compiler is already too slow, in fact there's a lot of work slated to try and make it faster.

Lots of effort went into studying the problem, so it most definitely isn't an issue of "can't be bothered".

Re: Go 1.5 Release Notes

#37

Post by Zariel »

chimeracoder wrote: post #10
hencq wrote: post #7

The release notes mention the new Go compiler is about 2x slower than the old C based one. It also mentions there's ongoing work to improve this. I wonder if there are any estimates on how close to the original performance they think they can get. Do they expect to reach parity by, say, 1.6 or will it always be slower? For my tiny hobby projects, compile times aren't an issue at all so I'm asking purely out of curios…

> I wonder if there are any estimates on how close to the original performance they think they can get. Do they expect to reach parity by, say, 1.6 or will it always be slower? I imagine that's just a side-effect of rewriting the entire compiler; I'd expect the next versions to improve on the speed. Though in the meantime, if compilation time is an issue, you can always try gccgo. On my larger projects, it's slightly…

The new compiler is now garbage collected, and is generating lots of garbage, when the old compiler ran without any garbage collection. There is an interesting thread from the mailing list about this [0]

[0] https://groups.google.com/d/topic/golang-dev/6obxRcm-rqc/dis...

Re: Go 1.5 Release Notes

#38

Post by pcwalton »

crawshaw wrote: post #36
coldtea wrote: post #33

Earlier quoted context omitted.

All of the supposed reasons given in that post have been answered to death by multiple people (including PL experts), and none holds to much scrutiny. "We just can't be bothered" or "we don't think they're much good, and we don't have a need for them" would be a much more realistic answer.

I haven't seen any rejoinders to that document that contradict the fact that you pay for parametric polymorphism with either slower compilation or slower runtime. Go isn't interested in either being slow. Any generics solution has to have fast runtime, because they need to replace the builtin parametric slices and maps. And the compiler is already too slow, in fact there's a lot of work slated to try and make it fast…

> I haven't seen any rejoinders to that document that contradict the fact that you pay for parametric polymorphism with either slower compilation or slower runtime.

I think the error in that reasoning is attributing this issue to generics specifically when this is actually a problem with code reuse in general.

Say I have a linked list and want to use it to hold both integers or strings. My two options, in any language—whether that language has generics or not—are: (1) write specialized code for every type I want to use it with (go generate), potentially bloating the code and resulting in extra compilation time; (2) use some sort of existential type (interface{} in Go) and share the code but pay a performance cost at runtime. The dilemma arises because of the problem itself, not because of generics.

It is of course right that there is a tradeoff here (although there are many other potential solutions that aren't at one extreme or the other, .NET-style JIT compilation or intensional type analysis for example). But not having generics doesn't eliminate the tradeoff. Generics are just a way for the compiler to automate the work that a programmer would otherwise have to do. If you don't have generics, you still have that dilemma, except that you have to write the code yourself instead of the compiler doing it for you.

Re: Go 1.5 Release Notes

#40

Post by snuxoll »

aikah wrote: post #26
snuxoll wrote: post #22

Earlier quoted context omitted.

And still no generics. Honestly, at this point I just wish they'd add a 'void' alias for 'interface {}' so at least non-typesafe code was only as ugly as the equivalent C -_-

AFAIK you can create a named type from interface{} type V interface{} Don't hold your breath when it comes to generics. There is no way they can retrofit them without breaking the language, it's too late. Even features like covariance or unions are just out of question. An option would be to write a super-set of Go with generics that would compile to Go code. what it would do basically is use interface{} everywhere t…

> An option would be to write a super-set of Go with generics that would compile to Go code. what it would do basically is use interface{} everywhere the variable type T is required and insert type assertions for the user. Been thinking about that.

I think that's pretty much how you'd want to do it, it's type erasure just like generics in Java - sure, some people complain about not having reified generics, but I'm more concerned about type-safety, Go already has some runtime reflection capabilities anyway.

Post reply on HN