Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maybe adding generics to Go is about syntax after all

dave.cheney.net

Post reply on HN
Print view View original

31–40 of 92 posts

Re: Maybe adding generics to Go is about syntax after all

#31

Post by jonathankoren »

dagss wrote: post #12
jonathankoren wrote: post #7

If Go gets generics, maybe they’ll actually add an ‘implements’ keyword for interfaces and no more of this: var _ SomeIface = SomeConcrete{} var _ AnotherIface = SomeConcrete{} Just to see if you actually implemented all the signatures on the interface correctly.

Go has a lot of pain points but the one positive thing it has over other languages is how it handles interfaces. The whole point is that the caller can make new interfaces to fit existing structs in other libraries.

Actually, two of the pain points of Go is not knowing exactly what interfaces a class implements, and finding out that you misimplemented an interface but not discover this static analysis until you get a runtime type check failure.

All this pain for what boils down to not having to make a wrapper. Sure wrappers are dumb, but pushing a static analysis out to a run time error dumber, especially since implementing interfaces is a lot more common than wrapping 3rd party structs.

Re: Maybe adding generics to Go is about syntax after all

#32

Post by mopsy »

gregwebs wrote: post #16

This might be nice to use in the specific case. However, its important to note that in the general case, you need a type variable because it is used in multiple positions. In the function below (taken from the proposal), one is stating that T is the same type in all usages. func Join(type T strseq)(a []T, sep T) (ret T) This below version is different, each variable could be a different type (that satisfies strseq).…

As I understand, the type would be implicitly applied to every func/struc in scope (which I assume would be the package)

It work quite well for package like a Map so any data structure/algorithm. I suspect it would be less ideal for filter/map/reduce.

Re: Maybe adding generics to Go is about syntax after all

#33

Post by AnimalMuppet »

AnaniasAnanas wrote: post #23
jclulow wrote: post #14

Earlier quoted context omitted.

Because not everyone agrees (thankfully!) that syntax is uninteresting or irrelevant, or that Lisp is some amazing global aesthetic or ergonomic maximum.

Why thankfully?

Because syntax actually does matter, and Lisp is only a local maximum. Thinking otherwise causes pain, as people try to use Lisp in situations where it is not the best answer, and is therefore harder to use than other languages.

So, "thankfully", because acknowledging reality here means not having to live with the pain of using a language that is sub-optimal for the problem you're working on.

Re: Maybe adding generics to Go is about syntax after all

#35

Post by fusiongyro »

wbl wrote: post #20

Why not adopt standard ML's polymorphism semantics? Is there some type theory issue I don't know about preventing that?

I wish the world adopted ML's modules and functors. Especially higher-order functors, which are kind of an extension of the standard.

But I think Go is more worried about compiler performance, so if there are significant complexities in the surface syntax of generics or in their downstream consequences, it will be an impediment there. I think the people behind Go consider most type theory to be an impediment to productivity and would rather accept something simple with shortcomings they understand than try to do it "right." I think this is a perfect example of Unix's "worse is better" philosophy. Whether we agree with it or not is another question.

Re: Maybe adding generics to Go is about syntax after all

#36

Post by artursapek »

cyphar wrote: post #11
jonathankoren wrote: post #7

If Go gets generics, maybe they’ll actually add an ‘implements’ keyword for interfaces and no more of this: var _ SomeIface = SomeConcrete{} var _ AnotherIface = SomeConcrete{} Just to see if you actually implemented all the signatures on the interface correctly.

Actually one of the main benefits of Go over Java is the lack of a requirement for "implements" because otherwise it means that you cannot use a type in a context where the original developer did not intend it to be used (though I imagine you're implying that it would not be required). However quite a few Go developers now use interfaces with an unexported method specifically to stop users from misusing their types i…

> However quite a few Go developers now use interfaces with an unexported method specifically to stop users from misusing their types in a context they didn't intend. I guess it's come full circle.

What a horrible hack. Why bother with that? Either export your interface, your don't.

Re: Maybe adding generics to Go is about syntax after all

#37

Post by pdeuchler »

cyphar wrote: post #2

On the topic of "syntax is important" (though not related to generics -- other than by aside to the Result type) I'm still not a huge fan of the handle syntax -- I reckon something more similar to Rust's .map_err() would be handled better because lots of people now use pkg/errors[1] which has the boilerplate of if err != nil { return errors.Wrap(err, "some message that is unique to this line") } and the handle constr…

As someone who just went to gophercon I'm still confused why they're tackling error handling first, and then generics. I would imagine tackling errors in Go 2.1 with the help of generics would make for a much much cleaner solution... if we even need one (i'm not fully convinced verbose error checking is as bad as people say it is)

Re: Maybe adding generics to Go is about syntax after all

#38

Post by artursapek »

I was at Gophercon and saw Russ's video where he spent 30 seconds explaining what generics were to the audience and showed a half-baked example of the syntax they are considering. I've been using Go for almost 5 years now and have no desire to see generics introduced. It would ruin what is currently a very simple and easy-to-use language. Am I the only one who is hoping this whole thing fizzles out?

Re: Maybe adding generics to Go is about syntax after all

#39

Post by cyphar »

artursapek wrote: post #36
cyphar wrote: post #11

Earlier quoted context omitted.

Actually one of the main benefits of Go over Java is the lack of a requirement for "implements" because otherwise it means that you cannot use a type in a context where the original developer did not intend it to be used (though I imagine you're implying that it would not be required). However quite a few Go developers now use interfaces with an unexported method specifically to stop users from misusing their types i…

> However quite a few Go developers now use interfaces with an unexported method specifically to stop users from misusing their types in a context they didn't intend. I guess it's come full circle. What a horrible hack. Why bother with that? Either export your interface, your don't.

Well -- what if you have multiple implementations of an interface and you want users to be able to choose between them (or rather, you want them to be able to write functions around your interfaces)? I don't really like it much either, but it's a completely valid usecase for unexported methods. In fact I'm pretty sure this was an example from the language developers for why you can have unexported interface methods in Go.

Re: Maybe adding generics to Go is about syntax after all

#40

Post by cyphar »

pdeuchler wrote: post #37
cyphar wrote: post #2

On the topic of "syntax is important" (though not related to generics -- other than by aside to the Result type) I'm still not a huge fan of the handle syntax -- I reckon something more similar to Rust's .map_err() would be handled better because lots of people now use pkg/errors[1] which has the boilerplate of if err != nil { return errors.Wrap(err, "some message that is unique to this line") } and the handle constr…

As someone who just went to gophercon I'm still confused why they're tackling error handling first, and then generics. I would imagine tackling errors in Go 2.1 with the help of generics would make for a much much cleaner solution... if we even need one (i'm not fully convinced verbose error checking is as bad as people say it is)

(I agree that waiting until generics were ironed out would have been a better idea, because we already have pretty large communities around existing error handling libraries. Unfortunately this is a pattern of the Go language designers -- they have often ignored community consensus around an issue, like they did with vendor/ and other similar issues).

My main issue with it (aside from making memes about RSI) is that it actually dilutes your test coverage artificially. 'go tool cover' instruments line-by-line (technically I think it's statement-by-statement but that's not relevant here) and so having a dummy line like

    if err != nil {
        return err
    }
where you aren't doing anything useful with the error decreases your test coverage over a line which is not only obviously correct but might also be impossible to test (some APIs have an error return even though they can never fail in most usecases -- and as a user of the library it's better to be safe and check the error anyway). A perfect example of this is the Read() interface from math/rand -- it is impossible for this to return an error and yet you definitely should check the return value from Read() and it would be irresponsible not to.
Post reply on HN