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

21–30 of 670 posts

Re: Toward Go 2

#21

Post by cat199 »

HarkMamilton wrote: post #10
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 think this is too little, too late. Anyone who saw an advantage to using generic programming is already using something else. They've already invested resources in something besides Go; why spend the effort to switch back for what will, at best, probably be very mediocre support for parametricity compared to whatever they're already using?

This presumes that:

a) generic programming is a new thing

b) any of those people you mention aren't using go for some things and other things where this feature is desired

c) that the feature will 'at best' be at level X

d) that level X won't be enough to satisfy some use cases

and a whole host of other things, not least of which the fact that go itself was invented to suit some purpose after other languages existed, and has been successful for many users

Re: Toward Go 2

#23

Post by masklinn »

JepZ wrote: post #15

I know there is a lot of discussion about generics, but I am not sure if that is missing the point. I mean 'generics' sounds like a complex concept from the java development and I am uncertain if that's really what we need in go. From my experience I think we should talk about container formats because they make 80% of what we would like to have generics for. Actually, go feels as if it has only two container data st…

> I mean 'generics' sounds like a complex concept from the java development and I am uncertain if that's really what we need in go.

That's inane and insane. Java generics do almost nothing, they don't even exist at runtime in a language with (much like Go) heavy runtime semantics. Here's what Java's generics do: get typechecked, and insert implicit casts.

> Yes, I am sure there are more container formats

First, you forgot Channels and arrays (which are distinct from slices) as well as "range" to iterate over them generically, second there are more containers than that in Go's own standard library: https://golang.org/pkg/container/, https://github.com/golang/go/issues/18177

> it is possible to build your own, but I think it is not easy enough

What does that mean? It is not easy enough what? To write containers? To have generics?

Re: Toward Go 2

#24

Post by kardianos »

eropple wrote: post #12
Analemma_ wrote: post #8

> 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. This is sampling bias at work. The people who need generics have long since given up on Go and no longer even bother participating in Go-related discussions, because they've believe it will never happen. Meanwhile, if you're still using Go, you must…

> no longer even bother participating in Go-related discussions, because they've believe it will never happen /raises hand I like when tools are good, but I've basically written off Go as a tool for generating unsustainable code right now (and a big part of it is the odious options, either type-unsafety or code generation, for things that are trivially handled by parametricity). If things change, I'll be happy to rev…

I think the Go team would still like to understand your production uses that caused you to write off Go. What is your problem domain? How would you accomplish that in Go? How did you actually solve your problem with a different language?

For me, user provided data structures are the only thing that comes to mind (sync.Map for example) in my production use of Go. But even then, my pain (time spent, errors made) due to a lack of generics is low.

You may have written off Go. But if you're willing, I bet the Go team would still like to read your production code use-cases that caused you to do so.

Re: Toward Go 2

#25

Post by munificent » 

    > 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 Dart's optional type system -- you can sneak around the type checker really easily anyway, so in most cases you can just use "dynamic" instead of a generic method and get your code to run. Of course, it won't be type safe, but it will at least mostly do what you want.

When we later moved to a sound static type system, generic methods were a key part of that. Even though end users don't define their own generic methods very often, they use them all the time. Critical common core library methods like Iterable.map() are generic methods and need to be in order to be safely, precisely typed.

This is partially because functional-styled code is fairly idiomatic on Dart. 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.

I do think if you add generic types without generic methods, you will run into their lack. Methods are how you abstract over and reuse behavior. If you have generic methods without generic classes, you lose the ability to abstract over operations that happen to use generic classes.

A simple example is a constructor function. If you define a generic class that needs some kind of initialization (discouraged in Go, but it still happens), you really need that constructor to be generic too.

Re: Toward Go 2

#26

Post by masklinn »

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

40, nearing on 45:

> Milner, R., Morris, L., Newey, M. "A Logic for Computable Functions with reflexive and polymorphic types", Proc. Conference on Proving and Improving Programs, Arc-et-Senans (1975)

Re: Toward Go 2

#27

Post by piinbinary »

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.

I'm not sure why this is being downvoted. These are perfect examples of where generics would make a genuine improvement.

Re: Toward Go 2

#28

Post by eropple »

JepZ wrote: post #15

I know there is a lot of discussion about generics, but I am not sure if that is missing the point. I mean 'generics' sounds like a complex concept from the java development and I am uncertain if that's really what we need in go. From my experience I think we should talk about container formats because they make 80% of what we would like to have generics for. Actually, go feels as if it has only two container data st…

> they make 80% of what we would like to have generics for

I regularly use generics in other languages for tasks unrelated to "containers"/data structures. They allow me to write less code and have the compiler check my mistakes.

Containers are frequently where people start with parameterized types, but once you are in the habit of using them actively that's rarely where you stop.

Re: Toward Go 2

#29

Post by cdnsteve »

"We estimate that there are at least half a million Go developers worldwide, which means there are millions of Go source files and at least a billion of lines of Go code"

Re: Toward Go 2

#30

Post by masklinn »

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[0] it is because they special-cased a few generic structures as builtin very early on, unlike, say, Java (which only had arrays as a typed datastucture).

[0] Java and C# are could hardly be more imperative, hell Java is only just adding anonymous functions

Post reply on HN