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

151–160 of 670 posts

Re: Toward Go 2

#151

Post by willtim »

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

In Haskell (and I believe Scala), one can use pragma hints to specify to the compiler when to specialise, if performance becomes a problem. So I don't see this as an argument against parametric polymorphism.

Re: Toward Go 2

#152

Post by tumdum_ »

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…

Using interface{} you never get implicit/silent conversion, so Go type system is strong (and static obviously). It just lack parametric polymorphism.

Re: Toward Go 2

#153

Post by makecheck »

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 Python was too ingrained to pull a "Python 3"; Go is newer, and this could be more like a "Swift 3".

Break early and then stabilize for a long time; just make sure everybody knows the plan.

Re: Toward Go 2

#154

Post by hdhzy »

imsofuture wrote: post #44
saghm wrote: post #35

Earlier quoted context omitted.

I haven't programmed in Go, but from what I understand, Go's explicit error handling isn't enforced by the type system, as you can leave off an `if err { ... }` check and everything still compiles. I think adding a generic result/error type (like the Result type in Rust or the Either type in Haskell) would be a pretty useful feature, as currently the error handling sits in kind of a weird place between forced handlin…

Go's errors are really nice (if a bit repetitive) in my opinion. Type signatures enforce that you accept and acknowledge an error returned from an invocation, but leave it up to you to handle, pass along, or silently swallow.

So... Just like checked exceptions in Java?

Re: Toward Go 2

#155

Post by anth1988 »

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…

This is just another way of saying fuck generics. They really can't see any solvable problems after years of people asking for generics?

Re: Toward Go 2

#156

Post by nuggien »

johansch wrote: post #114

My main wish: Please don't refuse to compile just because there are unused imports. Please do warn, and loudly say it's NON-CONFORMANT or whatever will embarass me enough from sharing my piece of Go code with someone else.. but.. can I please just run my code, in private, when experimenting?

Just use an editor that has goimports hooked up to run on save.

Re: Toward Go 2

#158

Post by lemoncucumber »

As much as I want them to fix the big things like lack of generics, I hope they fix some of the little things that the compiler doesn't catch but could/should. One that comes to mind is how easy it is to accidentally write:

  for foo := range(bar)
Instead of:

  for _, foo := range(bar)
When you just want to iterate over the contents of a slice and don't care about the indices. Failing to unpack both the index and the value should be a compile error.

Re: Toward Go 2

#160

Post by littlestymaar »

Spiritus wrote: post #36
solomatov wrote: post #18

Earlier quoted context omitted.

I would start using Go in my projects if it introduces generics. It's a show stopper for me.

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.

Not the GP, but you can think about generics as a better kind of interfaces :

- performance wise: no dynamic dispatch, means no virtual function call, means faster code.

- type safety: let say I want a data structure that can store anything but everything in it must be the same type. You just can't do that with Go's current type system without introspection (which is cumbersome and really slow).

Generics already exists in Go : maps, slices and channels and generic, and it was mandatory for performance reason. The problem of not having generics is that the community can't build its own implementation of useful data structures : for instance, until the last release Go lacked a thread-safe map. That's fine, let's use a library for that … Nope, can't implement that because, “no generics”.

Generics are rarely useful in your own code, but they allow people to create good abstractions in their libraries. Without generics, the ecosystem growth is limited.

Post reply on HN