arXiv:2005.11710cs.PL
We describe a design for generics in Go inspired by previous work on Featherweight Java by Igarashi, Pierce, and Wadler. Whereas subtyping in Java is nominal, in Go it is structural, and whereas generics in Java are defined via erasure, in Go we use monomorphisation. Although monomorphisation is widely used, we are one of the first to formalise it. Our design also supports a solution to The Expression Problem.
Linked by 16 identifiable commenters in 21 comments across 19 threads, from Jun 2020 to Aug 2026. Found in 3 HN submissions from May 2020 to Dec 2021. Open submission discussions.
> I'm not interested in what "PL (programming language) people" have to say about it. They dislike all generic/parametric polymorphism implementations except their pet language that no one uses. That's strange. I seem to recall the PL community invented the generics system for…
Are we just ignoring when they invited Philip “Featherweight Java” Wadler to help them design Go generics? https://arxiv.org/abs/2005.11710 Or that Robert Griesemer literally is a language PhD, whose thesis was supervised by a little fellow by the name of “Niklaus Wirth”?…
> Most anything in software can easily end up Turing-complete though. not really, if you actually pay attention when youre designing the type system: https://arxiv.org/pdf/2005.11710.pdf
Which proposal would you rather had been adopted instead? It's strange to describe the current implementation has "half thought". A lot of work was done to make sure it was correct: https://arxiv.org/pdf/2005.11710.pdf It's probably one of the most carefully thought through…
Philip Walder, who contributed to the design of Haskell (according to wikipedia, haven't dug deep here) worked with the Go developers on a PL theory underpinning for Go's generics: https://arxiv.org/abs/2005.11710 So, in fact, industry didn't ignore PL theory and research at all.
> I'm not sure what the difference is with regards to pointers. In C# most objects are 'class' objects, which are implicitly passed by pointer, although some are 'struct' objects passed by value. In Go rather than making the decision once at the type level, the decision to pass…
> Is it a better bet to move on and go full Rust If you don't like generics you shouldn't use Rust. You can't escape them in Rust. The designers repeated the mistake of C++ and made it a language feature kitchen sink. It's an unholy mess. You'll find yourself constantly fighting…
> Rob was opposing generics from the start. That's simply not true. > he was firmly saying no. I'm sure you cannot find a single instance where he firmly says no to generics. He wrote in the FAQ that Go might get generics one day and that they are continuing to think about it.…
> purely for ideological reasons There are no ideological reasons. https://github.com/golang/go/commit/dd64f86e0874804d0ec5b713... "Generics may well come at some point." https://golang.org/doc/faq#generics "A language proposal implementing a form of generic types has been…
I'm studying programming language semantics and papers like these are quite valuable in understanding type systems of real languages, see also Featherweight Java[0] and Featherweight Go[1]. At first it looks like a lot to take in, but when you start with far simpler type systems…
Philip Wadler ? https://arxiv.org/abs/2005.11710
Since type erasure was mentioned, it's worth noting that Philip Wadler (of Haskell fame) was involved both in the design of Java generics [0] and of Go generics [1]. (Perhaps I should clarify that I don't have a strong opinion on type erasure.) [0]…
My understanding from the “Featherweight Go” paper https://arxiv.org/abs/2005.11710 is that generic types will not simply be a synonym for interface{} because the compiler will be able to monomorphize them - they do not require dynamic dispatch like interfaces.
> My understanding from the “Featherweight Go” paper https://arxiv.org/abs/2005.11710 is that generic types will not simply be a synonym for interface{} The `any` constraint is a synonym for the `interface{}` constraint.
> It's complicated and there was miscommunication but it forms part of the pattern. It looks like from that thread that the Go team was never on board with certain technical aspects of how dep was implemented. Obviously there are trade offs so it's hard to determine what answer…
> And Go people's common refusal to look much further, and especially not into academia.. I don't think that's a fair statement, given Phil Wadler's formal work on generics in Go - "Featherweight Go" (https://arxiv.org/abs/2005.11710) - which is acknowledged here…
Ah, the irony, "Featherweight Go" https://arxiv.org/abs/2005.11710 -- Proc. ACM Program. Lang., Vol. 1, No. OOPSLA It appears Go needs PhDs after all.
If this follows the monomorphic approach described in Featherweight Go [1][2], they will at least avoid problems caused by type erasure and avoid too much runtime overhead. 1. https://arxiv.org/abs/2005.11710 2. https://news.ycombinator.com/item?id=23368453
The Featherweight Go paper also just recently came out, which is an important step: https://arxiv.org/abs/2005.11710
Here's the corresponding paper: https://arxiv.org/abs/2005.11710
Connected through shared HN threads, not inferred similarity or a recommendation.
> it finally took convincing Philip Wadler (of Haskell and Java generics fame) to help. Without that lucky break [...] Go probably still wouldn't have generics. Small correction, I think: My understanding is the core Go team was already well on its way to doing generics before…
typical182View on HNParent context