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

61–70 of 670 posts

Re: Toward Go 2

#61

Post by pjmlp »

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 already be happy if they supported generics like CLU did in 1975, no need for nothing too fancy.

Re: Toward Go 2

#62

Post by masklinn »

endymi0n wrote: post #39
masklinn wrote: post #26

Earlier quoted context omitted.

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

Guess what: they did. https://news.ycombinator.com/item?id=8756683 They just weren't ready to make any of the significant tradeoffs other languages have to do in order to support them. Whether that's a good outcome, I'm not fully sure - but there's definitely a lot of research in that area.

> Guess what: they did.

Yeah as pointed out in that very thread by pjmlp:

    As usual, it lacks discussion about generics in:
    Eiffel
    Ada
    Modula-3
    D
    MLton
    .NET
    Rust
    Haskell
    OCaml
    Sather
    BETA
    CLU
Oh wait, they're pointing out that none of these is even remotely being discussed in the article hinting that they did not, in fact, and much prefer taking down strawmen they built from some sort of daguerreotypes of Java and C++.

> They just weren't ready to make any of the significant tradeoffs other languages have to do in order to support them.

Ah yes, the ever so convenient but never actually clarified "tradeoffs", which only ever happen for generics but oddly enough apparently don't happen for any other feature.

> there's definitely a lot of research in that area.

That there is, would be nice if Go's designers ever bothered actually using it.

Re: Toward Go 2

#63

Post by artursapek »

frik wrote: post #41
alexandernst wrote: post #22

How about fixing all the GOPATH crap?

++ Now we have at least vendor. But this alien-style fixed paths is really annoying - no other language forces such GOPATH crap. Please remove this limitation from Go 2!

What exactly is wrong with GOPATH? I find it much easier to reason about than imports in say Ruby or Python, which are global names with no hierarchy and are resolved in much less obvious ways.

Re: Toward Go 2

#64

Post by twblalock »

tomovo wrote: post #11
tomovo wrote: post #9

Earlier quoted context omitted.

Go 2, codename "Hell with generics". Just kidding of course. I am sure some useful form of generics will eventually find its way in.

More importantly though, looking at C++ I think it may be hard to come up with a generics system that doesn't lend itself to abuse and ridiculous mega constructs. I would love to see something that provides power in ways that disallow craziness (Boost Spirit kind) but provide enough power to avoid all the cases that suffer without generics.

The craziness is preferable to passing void* or Object or Interface{} everywhere. At that point, you might as well use a language without strong typing, for all the safety you're going to get. You can end up with just as much craziness with void* and Object and Interface{}.

The Go team needs to stop trying to control what people do with their language. If people come up with crazy implementations, it's their own problem. It's up to the Go community to provide alternatives to prevent those crazy implementations from becoming standardized in Go programming culture. Refusing to implement generics because programmers might abuse them is paternalistic and counterproductive.

Re: Toward Go 2

#65

Post by Spiritus »

Touche wrote: post #51
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.

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.

Re: Toward Go 2

#66

Post by artursapek »

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…

They're trying to avoid creating the new Python 3

Re: Toward Go 2

#67

Post by pjmlp »

crawshaw wrote: post #5
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…

Several members of the Go team have invested significant effort in studying generics and designing proposals, since before Go 1.0. For example, Ian Lance Taylor published several of his previous efforts, which had shortcomings he was dissatisfied with. I believe your impression of the Go team's position has been corrupted (likely unintentionally) by intermediaries.

Except they seem to focus only on Java, .NET and C++, forgetting that generics were initially implemented in CLU back in 1975, and there were several programming languages since those days that had some form of generics being designed into them.

Re: Toward Go 2

#68

Post by brango »

artursapek wrote: post #63
frik wrote: post #41

Earlier quoted context omitted.

++ Now we have at least vendor. But this alien-style fixed paths is really annoying - no other language forces such GOPATH crap. Please remove this limitation from Go 2!

What exactly is wrong with GOPATH? I find it much easier to reason about than imports in say Ruby or Python, which are global names with no hierarchy and are resolved in much less obvious ways.

There's no obvious way to separate personal work, from work work, from exploratory work, from any other way you want to categorise your source directories. You just have to chuck them all in the same root and hope you can remember what each project is for.

Re: Toward Go 2

#69

Post by pjmlp »

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!

You forgot CLU in 1975. :)

Re: Toward Go 2

#70

Post by pcwalton »

endymi0n wrote: post #39
masklinn wrote: post #26

Earlier quoted context omitted.

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

Guess what: they did. https://news.ycombinator.com/item?id=8756683 They just weren't ready to make any of the significant tradeoffs other languages have to do in order to support them. Whether that's a good outcome, I'm not fully sure - but there's definitely a lot of research in that area.

The basic tradeoff is monomorphization (code duplication) vs. boxing (in Go speak, interface{}). The problem with saying "well, this is a tradeoff and both sides have downsides, so we won't do anything" is that the tradeoff still exists—it's just something that manually has to be done by the programmer instead of something that the compiler can do. In Go, the monomorphization approach is done with code duplication (either manually or with go generate), while the boxing approach is done with interface{}. Adding generics to the language just automates one or both of the approaches.

The idea that the monomorphization/boxing tradeoff can be dodged by not having generics in the language is a fallacy. In Go, today, you as a programmer already have to decide which side of the tradeoff you want every time you write something that could be generic. It's just that the compiler doesn't help you at all.

Post reply on HN