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

71–80 of 670 posts

Re: Toward Go 2

#71

Post by bpicolo »

xienze wrote: post #43
TheDong wrote: post #4

Earlier quoted context omitted.

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. They aren't because the prevailing attitude is "what do you need generics for? Just do a cast!" The issue is the Go developers are unwilling to consider generics until someone can come up with a problem that absolutely, positively cannot be solved without generics. And of course there isn't one.

I mean, having to cast after every single call to heap is a problem.

Go is turing complete already, so all problems are already able to be solved. :)

Re: Toward Go 2

#72

Post by Spiritus »

the_mitsuhiko wrote: post #58
Spiritus wrote: post #36

Earlier quoted context omitted.

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.

The benefits of generics are well understood.

So why is he requesting feedback on the matter?

Re: Toward Go 2

#74

Post by seanwilson »

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!

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

Yeah, I find it strange how languages are trending at a glacially slow pace to having the same features that strongly typed functional programming languages have had for literally decades. It's like we're going to be using actual functional programming languages eventually but the only way it'll happen is to very slowly change what everyone is currently using in small steps.

Static types, immutability, type inference and non-null variables are popular design choices right now but they've been in functional programming languages for nearly 50 years. I'm still waiting for inductive types and pattern matching to turn up in a mainstream language and seeing them talked about like they're new concepts.

Re: Toward Go 2

#75

Post by nemo1618 »

solomatov wrote: post #18
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…

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

You might be interested in my side project: https://github.com/lukechampine/ply

It's a small superset of Go that allows you to call map/filter/reduce methods on any slice. It's not true generics (you can't define your own generic functions or types) but it covers the most common use case for me: declarative data processing.

Re: Toward Go 2

#76

Post by snuxoll »

masklinn wrote: post #30
munificent wrote: post #25

> 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. I work on the Dart language. Dart was initially designed with generic classes but not generic methods. Even at the time, some people on the team felt Dart should have had both. We proceeded that way for several years. It was annoying, but tolerable because of Dar…

> You see lots of higher-order methods for things like manipulating sequences. Go has lambdas, but stylistically tends to be more imperative, so I'm not sure if they'll feel the same pressure. `range` is generic, and by virtue of that is a builtin which only works with a subset of the also builtin magically generic types. The reason why Go "does not feel the same pressure" has nothing to do with its imperative style[…

Java has "had" anonymous functions for ages with anonymous inner classes, they just sucked as an implementation.

Re: Toward Go 2

#77

Post by masklinn »

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 don't have a System.Collections.Generic version) that's unlikely to be an issue.

Re: Toward Go 2

#78

Post by AaronFriel »

Spiritus wrote: post #65
Touche wrote: post #51

Earlier quoted context omitted.

Do you not see how this is an insulting question? You know very well the use cases for generics. You do not need users to present new ones. You can literally Google "generics use cases" and get hundreds of thousands of results that directly answer that question.

Did you even read the blog post? Such feedback was explicitly asked for.

I think the problem everyone has swallowing that ask is that the value of generics is that it's so widely taught, with so many use cases, and so much literature (academic and otherwise) that the suggestion that they need use cases is laughable.

What use cases do they need other than the extremely large body of public knowledge on the matter, and why would one more example change anyone's mind?

To me this represents the epitome of the insular and outwardly hostile attitude that the Go team has toward good ideas elsewhere in the CS world. Would it really make a difference to the team if I or anyone else were to hunt down specific examples and present them with problems solved with generics and stronger type systems?

I doubt it.

Re: Toward Go 2

#80

Post by dvt »

munificent wrote: post #25

> 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. I work on the Dart language. Dart was initially designed with generic classes but not generic methods. Even at the time, some people on the team felt Dart should have had both. We proceeded that way for several years. It was annoying, but tolerable because of Dar…

I edited a book on Dart a few years ago. It's a shame the language hasn't gotten much traction outside of Google, as I enjoyed learning and using it.
Post reply on HN