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

81–90 of 670 posts

Re: Toward Go 2

#81

Post by jcadam »

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…

After some initial enthusiasm due to its gentle learning curve (actually, the Golang learning curve is nearly non-existent for an experienced programmer), I got sick of Go programming pretty quickly. Writing anything non-trivial will have you fighting against the limitations of the language (e.g., lack of generics which is particularly aggravating when trying to write a library).

I've mostly moved on to Clojure for programming backend services. I still use Go for the occasional small utility program due to its speed and ease of deployment, though.

Re: Toward Go 2

#82

Post by lomnakkus »

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.

Asking for use cases when the use cases and benefits are already well-known seems pretty disingenuous to me. (Of both you and the blog post.)

... but, hey, just to indulge you, a few off the top of my head:

- Generic containers in libraries (aka not built-in)

- Parametricity to restrict user-supplied implementations of interfaces; not quite as valuable in a language with casts, etc., but still reasonably valuable.

- To give a sound account for the currently-magic built-in types.

That should be enough, frankly, but I'm sure I could come up with more if I were to spend 5 more minutes on it...

Can we stop pretending that they don't know of any compelling use cases now?

Re: Toward Go 2

#83

Post by masklinn »

pcwalton wrote: post #70
endymi0n wrote: post #39

Earlier quoted context omitted.

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 (…

> The basic tradeoff is monomorphization (code duplication) vs. boxing (in Go speak, interface{}).

And even that is not the whole story, just because you reify generics does not mean you have to monomorphise everything, Microsoft's C# compiler only monomorphises value types.

Also Go may box in other contexts than interfaces depending on escape analysis (according to https://golang.org/doc/faq#stack_or_heap).

Re: Toward Go 2

#84

Post by ovao »

cdnsteve wrote: post #29

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

Perhaps fewer than a billion lines of Go code if there were generics.

Re: Toward Go 2

#85

Post by masklinn »

pjmlp wrote: post #67
crawshaw wrote: post #5

Earlier quoted context omitted.

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.

> Except they seem to focus only on Java, .NET and C++

C# isn't mentioned in any of the previous proposals, only Java, C++ and C.

Re: Toward Go 2

#86

Post by pjmlp »

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 kind of think the same way, but thanks to Docker and K8s success, it means we might have to deal with Go code regardless how we think about it.

Re: Toward Go 2

#87

Post by ainar-g »

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…

(Copying my reply from Reddit.)

>If you finally have the opportunity to break backwards-compatibility, just do it.

I think Russ explained pretty clearly why this is a bad idea. Remember Python 3? Angular 2? We don't want that to happen with Go 2.0.

>Additionally, I'm of the opinion that more projects should adopt faster release cycles.

I am of the opposite opinion. In fact, I consider quick releases to be harmful. Releases should be planned and executed very carefully. There are production codebases with millions of lines of Go code. Updating them every month means that no progress will be made at all. The current pace is very pleasant, as most of the codebases I work with can benefit from a leap to newer version every six months.

Re: Toward Go 2

#88

Post by jcstk »

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…

Ditto on generic methods both changing the game for Dart and being necessary. I spend most of my time in Dart, Swift and ObjC, and I've built serious applications in Erlang and Java. All of which I like for different reasons.

My opinion is that Dart's type system is the optimal type system. It allows for statically typed API surface, but at the same time, I can still add some dynamic voodoo under the surface and enable productive meta-programming.

Re: Toward Go 2

#89

Post by Spiritus »

lomnakkus wrote: post #82
Spiritus wrote: post #65

Earlier quoted context omitted.

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

Asking for use cases when the use cases and benefits are already well-known seems pretty disingenuous to me. (Of both you and the blog post.) ... but, hey, just to indulge you, a few off the top of my head: - Generic containers in libraries (aka not built-in) - Parametricity to restrict user-supplied implementations of interfaces; not quite as valuable in a language with casts, etc., but still reasonably valuable. -…

I was merely suggesting to indulge the author, especially now that generics might actually happen.

Re: Toward Go 2

#90

Post by JBReefer »

seanwilson wrote: post #74
wheaties wrote: post #16

Earlier quoted context omitted.

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 actua…

C# is adding pattern matching in the upcoming release, and to your point, people are acting like it's the new hotness.
Post reply on HN