News for hackers. Stuff that matters.
Re:Expectations for generics in Go 1.18 by Joker_vD on Thursday October 28, 2021 @08:40AM (#29025366)
C# mostly gets away with it because it has JIT support for it; in the end you still need to generate code for every data-size it's used with. Obviously, if all data are passed by reference you'd only need to generate code for the size of the pointer.

Even in C#, generics are sort-of second class:

    interface IMyLovelyADT { R Accept<R>(IMyLovelyADTVisitor<R> visitor); }
is not isomorphic to

    Func<IMyLovelyADTVisitor<R>, R>
The interface is strictly more flexible because it's non-generic, see my comment at [0] for an actual code example (it's quite long) if you're interested, but the gist is "you need a non-generic wrapper interface IMyLovelyADT: it essentially does the same job as Haskell's forall, since generic types are not quite proper types in C#'s type system. Interestingly enough, upcoming Go 2's generics will not support this scenario: a method inside an interface will be able to use only the generic parameters that the interface itself declares."

[0] https://blog.ploeh.dk/2021/08/03/the-tennis-kata-revisited/

Re:Expectations for generics in Go 1.18 by mseepgood on Thursday October 28, 2021 @10:07AM (#29026285)
> Interestingly enough, upcoming Go 2's generics

It will be Go 1.18, not Go 2.

Re:Expectations for generics in Go 1.18 by Joker_vD on Thursday October 28, 2021 @11:02AM (#29026912)
They've been discussed as one of the several "feature proposals for Go 2.0" for couple of years, the playground for them is called "https://go2goplay.golang.org/", the issues with them go into "cmd/go2go" tag on Github, so that's why I called them "Go 2's generics".

And weren't they supposed to be in Go 1.17 but then got delayed?