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

Toward Go 2

blog.golang.org

Post reply on HN
Print view View original

161–170 of 670 posts

Re: Toward Go 2

#161

Post by anth1988 »

wheaties wrote: post #16
fusiongyro wrote: post #2

The paragraph I was looking for is this: > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can't answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use case…

If they want to "learn" about generics perhaps they can read the literature of the past 30yrs and look at how other languages have adopted those learnings: Java, C#, Haskell, OCaml and Coq. Look, even allowing type aliases to become part of an interface declaration would be a HUGE win. You can't currently write portable arbitrary data structures without reimplementing them with a code generator. Ugh!

> perhaps they can read the literature of the past 30yrs

You realize this post is talking about Go right? /s

Re: Toward Go 2

#162

Post by slantedview »

fusiongyro wrote: post #2

The paragraph I was looking for is this: > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can't answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use case…

The idea of needing to come up with use cases for generics is baffling. The existence of generics in numerous other languages already support of plethora of use cases. I really don't get that statement at all.

Re: Toward Go 2

#164

Post by hdhzy »

bad_user wrote: post #48

Java`s generics have had issues due to use site variance, plus the language isn't expressive enough, leading its users into a corner where they start wishing for reified generics (although arguably it's a case of missing the forest from the trees). But even so, even with all the shortcomings, once Java 5 was released people migrated to usage of generics, even if generics in Java are totally optional by design. My gue…

> Java`s generics have had issues due to use site variance

Use site variance can be really powerful when you're dealing with invariant data structures like Lists. You can then treat them like covariant or contravariant depending on a particular method call at hand.

Re: Toward Go 2

#165

Post by jerf »

TheDong wrote: post #4
fusiongyro wrote: post #2

The paragraph I was looking for is this: > For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can't answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use case…

The fact that go1.9 will include a "sync.Map" type which should be generic, but can't be due to the language's limitations should already answer that. See also all of the "container" portion of the stdlib: https://golang.org/pkg/container/ All of those should be generic, but aren't. Clearly there's already sufficient demand for generic collections just based on the stdlib and the fact sync.Map was seen as needed.

"All of those should be generic, but aren't."

I think even more damning then "these should be generic" is that there should be more of them. The real problem is the lack of generics inhibits the introduction of more data structures because they are hard to use.

It is true that arrays and maps/hashes take you a long way, but there's a lot of other useful data structures in the world. And despite the fact they may look easy at first, data structure code tends to be notoriously difficult to write both correctly and with high performance.

Re: Toward Go 2

#166

Post by the_duke »

tschellenbach wrote: post #112

The beauty of Go is that you get developer productivity pretty close to Ruby/Python levels with performance that is similar to Java/C++ Improvements to package management is probably the highest item on my wishlist for Go 2.

There is so much boilerplate you have to write that productivity drops considerably, both because you have to re-re-re-re-implement things (or use code generation) and because you need to scan lot's of redundant code before making sense of it.

The alternative is often to just use interface{}, which hurts performance and type safety.

Re: Toward Go 2

#167

Post by xenadu02 »

Spiritus wrote: post #36
solomatov wrote: post #18

Earlier quoted context omitted.

I would start using Go in my projects if it introduces generics. It's a show stopper for me.

The question is _why_ do you need generics, for what use case(s), etc? Saying “I need generics otherwise I won’t use Go” is exactly the type of feedback they don’t want. It seems like you’d have valuable feedback given that it’s a “showstopper” for you.

Create an ordered set or bloom filter type for Go and let us know how you make out.

Re: Toward Go 2

#168

Post by munificent »

masklinn wrote: post #77
EddieRingle wrote: post #46

> To minimize disruption, each change will require > careful thought, planning, and tooling, which in > turn limits the number of changes we can make. > Maybe we can do two or three, certainly not more than five. > ... I'm focusing today on possible major changes, > such as additional support for error handling, or > introducing immutable or read-only values, or adding > some form of generics, or other important topi…

Adding generics isn't even backwards-incompatible. AFAIK Java 1.5 was just fine with Java 1.4 code, and so was C# 2.0. The latter using reified generics (and not cheating with builtins) lead to the duplication of System.Collections but given builtins aside as of Go 1.9 it has under half a dozen non-generic collections (versus 25 types in System.Collections, though some of them didn't even make sense as generics and d…

> so was C# 2.0.

True, but C# also has nominal types, overloading, and explicit interface implementation. Adding generics without breaking existing code without those features looks very difficult to me.

Re: Toward Go 2

#169

Post by slantedview »

treehau5 wrote: post #140
solomatov wrote: post #18

Earlier quoted context omitted.

I would start using Go in my projects if it introduces generics. It's a show stopper for me.

Conversely, I would stop using Go in my projects if it introduces generics. If Go wants to be more sophisticated, there are other sophisticated languages I can use out there like Haskell, Rust, F#, Scala, etc. The problem I have learned in my career is "sophistication" usually gets in the way of getting things done because now you have all these clever developers full of hubris creating these novel implementations th…

> Conversely, I would stop using Go in my projects if it introduces generics

Depending how they're implemented, you might not have to use them (even via libraries). Not using the language altogether is a bit dramatic.

Post reply on HN