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

11–20 of 92 posts

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

#11

Post by cyphar »

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 in a context they didn't intend. I guess it's come full circle.

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

#12

Post by dagss »

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.

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

#13

Post by dagss »

slavapestov wrote: post #10
fithisux wrote: post #3

Why not reuse Common Lisp macros?

This is not a very useful thing to say. Macros have nothing to do with generics.

...except that both can be applied to solve the same problems.

And so they are in fact very related.

For instance with a macro you could do (made up syntax)

SortIntSlice = mymacros.MakeSorter!(int)

...then at compile time have code for sorting a slice of ints generated.

This is again similar to C++ templates (main difference is C++ will implicitly instantiate instead of explicitly).

And C++ doesn't need generocs because people use templates instead.

They really are in the same problem domain.

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

#14

Post by jclulow »

gnulinux wrote: post #6
fithisux wrote: post #3

Why not reuse Common Lisp macros?

Why not use lisp syntax, at all? Why do we have to reinvent syntax every single generation? I'm not an old school engineer (I'm in my early 20s and in my first job, freshly outta college) but I can't see why we don't use lisp, prolog or ML syntax for everything . Seems vastly better than C-like synaxes in all ways I can think of, easier to implement, easier to extend, easier to read (imho) etc... When I program even…

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

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

#15

Post by evmar »

gnulinux wrote: post #6
fithisux wrote: post #3

Why not reuse Common Lisp macros?

Why not use lisp syntax, at all? Why do we have to reinvent syntax every single generation? I'm not an old school engineer (I'm in my early 20s and in my first job, freshly outta college) but I can't see why we don't use lisp, prolog or ML syntax for everything . Seems vastly better than C-like synaxes in all ways I can think of, easier to implement, easier to extend, easier to read (imho) etc... When I program even…

I tinkered a bit (as many others have too!) with a lisp syntax for C, just to see what it'd feel like. That is, exact C semantics (so not inventing anything) but sexpressions.

What I remember struggling with is that it was surprisingly kind of hard to remember when parens are necessary where. For example you might define an if statement:

(if (> x 3) (printf ...))

Looks nice, but what about if you want multiple things in the body? Your options are

(if (> x 2) (progn (printf a) (return b)))

Where "progn" means "curly braces" effectively, or instead always requiring a list-shaped argument

(if (> x 2) ((printf a) (return b)))

which means in even the single-expression case you have to remember to always double-wrap

(if (> x 2) ((printf a)))

And now throw in handling of 'else' into the above. It gets surprisingly hard to use surprisingly fast. This problem repeats everywhere (function definitions, type declarations, for loops, and so on).

What all the above really clarified for me is that sexps work great in languages like lisp/scheme that are designed around them, but they don't solve syntax for free.

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

#16

Post by gregwebs »

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

    func Join(a []strseq, sep strseq) (ret strseq)

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

#17

Post by djur »

dagss wrote: post #13
slavapestov wrote: post #10

Earlier quoted context omitted.

This is not a very useful thing to say. Macros have nothing to do with generics.

...except that both can be applied to solve the same problems. And so they are in fact very related. For instance with a macro you could do (made up syntax) SortIntSlice = mymacros.MakeSorter!(int) ...then at compile time have code for sorting a slice of ints generated. This is again similar to C++ templates (main difference is C++ will implicitly instantiate instead of explicitly). And C++ doesn't need generocs beca…

Using macros to implement generics has the same problem that C++ templates have, which is described in the Go 2 generics proposal: it's difficult to provide clear error messages for developers in many cases. Functions parameterized on a single type are the easy problem to solve. Where things get thorny is when you parameterize on multiple types with various constraints and/or have some kind of interaction in the function body. The goal of the Go 2 generics contracts (and C++ concepts, Haskell typeclasses, Rust traits, etc.) is to make those expectations explicit.

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

#18

Post by ainar-g »

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…

Yeah. I always try to include some context with my errors, so the only actual uses for check/handle I have is

  handle err { log.Fatal(err) }
in quick "scripts". And even there I should probably provide more context. All clean-up work is already done in defer.

Overall, check/handle feels like a poorly-thought slap-on to me, on par with ON-units from PL/I[1]. And PL/I is not something you want as an inspiration.

[1] https://en.wikipedia.org/wiki/PL/I#ON-units_and_exception_ha...

Post reply on HN