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

121–130 of 670 posts

Re: Toward Go 2

#121

Post by wwweston »

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.

While "fuck generics" might be a low-resolution characterization, it's not entirely inaccurate, and the efforts of Taylor (and perhaps others) notwithstanding, as long as anyone is writing things like "I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve," there's reason to believe it's apt enough.

As other respondents to the GP comment show, it's not at all hard to come up with that ostensibly elusive picture if you're attending to it. So I suppose the obvious takeaway is that they're still not really attending to it. Which is fine, Go clearly has its niche and its fans, and people who don't want a pretty good Blub have other options.

Re: Toward Go 2

#122

Post by AnimalMuppet »

There are many comments griping about generics. There are many comments griping about the Go team daring to even ask what problems the lack of generics cause.

But take a look at this article about the design goals of Go: https://talks.golang.org/2012/splash.article Look especially at section 4, "Pain Points". That is what Go is trying to solve. So what the Go team is asking for, I suspect, is concrete ways that the lack of generics hinders Go from solving those problems.

You say those aren't your problems? That's fine. You're free to use Go for your problems, but you aren't their target audience. Feel free to use another language that is more to your liking.

Note well: I'm not on the Go team, and I don't speak for them. This is my impression of what's going on - that there's a disconnect in what they're asking for and what the comments here are supplying.

(And by the way, for those here who say - or imply - that the Go team is ignorant of other languages and techniques, note in section 7 the casual way they say "oh, yeah, this technique has been used since the 1970s, Modula 2 and Ada used it, so don't think we're so brilliant to have come up with this one". These people know their stuff, they know their history, they know more languages than you think they do. They probably know more languages than you do - even pjmlp. Stop assuming they're ignorant of how generics are done in other languages. Seriously. Just stop it.)

Re: Toward Go 2

#123

Post by seanmcdirmid »

masklinn wrote: post #105
JBReefer wrote: post #90

Earlier quoted context omitted.

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

That's not exactly surprising, the C# community has been doing that since the beginning of the language, anything not in the language is pointless academic wankery, and as soon as Microsoft announces it it's the best innovation in computing history since Microsoft was created. Source: got to interact with the community between the C# 1.0 and 4.0 releases (2.0 added generics, 3.0 added lambdas, neither feature was con…

> That's not exactly surprising, the C# community has been doing that since the beginning of the language, anything not in the language is pointless academic wankery, and as soon as Microsoft announces it it's the best innovation in computing history since Microsoft was created.

That isn't true inside Microsoft. Many of the people who work on C# are the same academic wanks that work on Scala or F#. C# has a different user base from those languages though, so they still have to be careful what they add to the language, and many language features are planned 3 or 4 versions in advance.

Re: Toward Go 2

#124

Post by zbobet2012 »

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.

That's going to happen before go 2. Go 1.9 / 1.10 time frame.

Re: Toward Go 2

#125

Post by liveoneggs »

stormbrew wrote: post #31
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 I were in the "go community" I would be pretty annoyed by this quote. I would find it dismissive of the literal years of people pointing at areas of their code that are bloated and less safe due to not having generics. It doesn't seem to me that there's a shortage of people pointing out real-world use cases at all, and I'm looking from the outside in.

the use of the monotonic click example is also interesting because of the similar tone of responses to that issue. I think it's just the rsc way.

basically it goes like: > If google isn't screaming about it, it's not important. > If google has a workaround, then it's fixed.

Re: Toward Go 2

#126

Post by baq »

frik wrote: post #110
kzisme wrote: post #73

Earlier quoted context omitted.

I'm also curious as to what issues you have come across with GOPATHS

Multiple unrelated Go projects in different repos located in different directories. No problem at all with very other language, except with Go - not possible! I want to open cmd.exe (Win) or bash (Linux) and cd to the directory and build. And not configure a GOPATH in the environment variables of the current user or pretend it to the batch script, set it in IntelliJ Go plugin, etc. It so unflexible, so arkward, and t…

make still works. I don't go build, I make build. Yes, you have to set it up for each project, but only once.

Give me cargo for go either way.

Re: Toward Go 2

#127

Post by camus2 »

jasonwatkinspdx wrote: post #118

Disclaimer: I mean this with love This post really frustrates me, because the lengthy discussion about identifying problems and implementing solutions is pure BS. Go read the years worth of tickets asking for monotonic time, and see how notable names in the core team responded. Pick any particular issue people commonly have with golang, and you'll likely find a ticket with the same pattern: overt dismissal, with a he…

> overt dismissal, with a heavy moralizing tone that you should feel bad for even asking about the issue

The attitude of Go community cannot be separated from the patronizing tone of Go maintainers. In fact it stems directly from the people @ Google working on Go. All the bullshit "you don't need that with go"™ comes directly from Pike,Cox and co. It's fine to be opinionated, but just admit these are opinions instead of engaging into the bullshit they engaged in for years when dismissing this or that problem as irrelevant.

Pike said "Go design" is done. Except that a language which design "is done" is a dead one.

Re: Toward Go 2

#128

Post by fixermark »

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…

The point of Go 2.0, IIUC, is that it throws away backwards-compatibility guarantees, so if they want to do something in Go 2.0 that breaks correct go1 code to support generics, that's on the table. So backwards-compatibility nastiness is not guaranteed.

Re: Toward Go 2

#129

Post by tomovo »

twblalock wrote: post #64
tomovo wrote: post #11

Earlier quoted context omitted.

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

"If people come up with crazy implementations, it's their own problem."

Some people are turned away from C++ after seeing random bits of crazy language/template misuse, although when used sanely C++ could've served them nicely for their job.

Same thing is going to happen to Swift very soon.

https://engineering.kitchenstories.io/comfortable-api-reques...

Those function signatures are definitely not... self-documenting, I'd say.

Re: Toward Go 2

#130

Post by maxekman »

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.

The sync.Map case for generics is a perfect example. Thanks for bringing it up.
Post reply on HN