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

91–100 of 670 posts

Re: Toward Go 2

#91

Post by jdmichal »

snuxoll wrote: post #76
masklinn wrote: post #30

Earlier quoted context omitted.

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

Absolutely correct. Lambdas are just shorthand for anonymous inner classes which implement an interface with only one method -- aka single abstract method (SAM) types.

For instance, you have two functions. One takes `Function` and the other takes `UnaryOperator`. Giving the "same" lambda to both functions will result in two anonymous inner types, one implementing both interfaces.

Re: Toward Go 2

#92

Post by matthewowen »

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?

Most of the projects which will use Go have not begun yet. Adding support means people may use Go for those future projects.

Re: Toward Go 2

#93

Post by artursapek »

brango wrote: post #68
artursapek wrote: post #63

Earlier quoted context omitted.

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.

What? Manage it the way you'd manage any other environment variables, like AWS_SECRET_ACCESS_KEY. That's exactly what a bash environment is for.

Re: Toward Go 2

#94

Post by zbobet2012 »

brango wrote: post #68
artursapek wrote: post #63

Earlier quoted context omitted.

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.

Uhh, just keep separate gopaths? I keep a separate go path per project.

Re: Toward Go 2

#95

Post by weberc2 »

callesgg wrote: post #6
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…

Not having generics makes it hard to do proper type safe functions and libraries. My specific problem when i realized it was an actual problem was when i tried to connect to a sql databse and working with a proper ORM.

Why does an ORM need generics? I ask because I've built something very like an ORM in Go and I didn't have any problem without generics. ADTs on the other hand...

Re: Toward Go 2

#96

Post by masklinn »

snuxoll wrote: post #76
masklinn wrote: post #30

Earlier quoted context omitted.

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

> they just sucked as an implementation.

They also sucked as an interface (for developers to use), resulting in them only being used when no other option was available (Comparable) or for cute hacks (double-brace initialisation).

Re: Toward Go 2

#97

Post by camus2 »

ainar-g wrote: post #87
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. Re…

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

The problem with Python 2/3 is that Python 3 didn't add enough new features to make people want to move to 3.

The problem with Angular 2 is that it just didn't know what it wanted to be.

If Go2 doesn't break enough yet still break it will be no different from Python 2/3 fiasco.

Go has serious design issues, the go team ignoring them hindered Go adoption pace at first place.

Re: Toward Go 2

#98

Post by masklinn »

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…

Surely if Go is considered mainstream so is Swift?

Re: Toward Go 2

#99

Post by weberc2 »

AaronFriel wrote: post #78
Spiritus wrote: post #65

Earlier quoted context omitted.

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

Off topic, but any chance UNI is your alma mater? I think we may have been there at the same time, judging by your name and some of your comments.

Re: Toward Go 2

#100

Post by [deleted] »

kardianos wrote: post #24
eropple wrote: post #12

Earlier quoted context omitted.

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

[deleted]
Post reply on HN