This is a bit of a tangent, but Go generics aren't monomorphized. Each instantiation is "stenciled" down to its GC shape and then the differences among types with the same shape are handled using a "dictionary" which is kind of like Swift's witness tables or Go's own interface vtables. See this description for details: https://github.com/golang/proposal/blob/master/design/generi...
The typical end result sits somewhere between monomorphization and type erasure in terms of generated code and runtime indirection.
In 2026 is an exciting year for the Rust compiler (and me)golang
proposal
HTML2015–2026
golang / proposal
proposal
Go Project Design Documents
82Distinct people
100Mentions
0Explicit recommenders
3.5KGitHub stars
What to know before exploring
What it is
Go Project Design Documents
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- golang/go · linked in 12 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year100 dated mentions
Observed mentions: 2015-10-01 02:58:35 UTC to 2026-10-20 22:40:57 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 7 | 6 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 14 | 2 | 12 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 16 | 5 | 11 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 14 | 4 | 10 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 11 | 3 | 8 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 11 | 3 | 8 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 6 | 0 | 6 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 4 | 0 | 4 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Proposing Changes to Go
Introduction
The Go project's development process is design-driven.
Significant changes to the language, libraries, or tools
(which includes API changes in the main repo and all golang.org/x repos,
as well as command-line changes to the go command)
must be first discussed, and sometimes formally documented,
before they can be implemented.
This document describes the process for proposing, documenting, and
implementing changes to the Go project.
To learn more about Go's origins and development process, see the talks
How Go Was Made,
The Evolution of Go,
and Go, Open Source, Community
from GopherCon 2015.
The Proposal Process
The proposal process is the process for reviewing a proposal and reaching
a decision about whether to accept or decline the proposal.
The proposal author creates a brief issue describing the proposal.
Note: There is no need for a design document at this point.
Note: A non-proposal issue can be turned into a proposal by simply adding the proposal label.
Note: Language changes should follow a separate template
A discussion on the issue tracker aims to triage the proposal into one of three outcomes:
Accept proposal, or
decline proposal, or
ask for a design doc.
If the proposal is accepted or declined, the process is done.
Otherwise the discussion is expected to identify concerns that
should be addressed in a more detailed design.
The proposal author writes a design doc to work out details of the proposed
design and address the concerns raised in the initial discussion.
Once comments and revisions on the design doc wind down, there is a final
discussion on the issue, to reach one of two outcomes:
Accept proposal or
decline proposal.
After the proposal is accepted or declined (whether after step 2 or step 4),
implementation work proceeds in the same way as any other contribution.
Detail
Goals
Make sure that proposals get a proper, fair, timely, recorded evaluation with
a clear answer.
Make past proposals easy to find, to avoid duplicated effort.
If a design doc is needed, make sure contributors know how to write a good one.
Definitions
A proposal is a suggestion filed as a GitHub issue, identified by having
the Proposal label.
A design doc is the expanded form of a proposal, written when the
proposal needs more careful explanation and consideration.
Scope
The proposal process should be used for any notable change or addition to the
language, libraries and tools.
“Notable” includes (but is not limited to):
API changes in the main repo and all golang.org/x repos.
Command-line changes to the go command.
Any visible behavior changes that need a GODEBUG setting for compatibility.
Any other visible behavior changes in existing functionality.
Adoption or use of new protocols, protocol versions, cryptographic algorithms, and the like,
even in an implementation.
Such changes are externally visible and require discussion and probably a GODEBUG setting.
Since proposals begin (and will often end) with the filing of an issue, even
small changes can go through the proposal process if appropriate.
Deciding what is appropriate is matter of judgment we will refine through
experience.
If in doubt, file a proposal.
There is a short list of changes that are typically not in scope for the proposal process:
Making API changes in internal packages, since those APIs are not publicly visible.
Making API or command-line changes in golang.org/x/build, since that is code to run the Go project, not for users to import and depend on.
Adding new system call numbers or direct system call wrappers (//sys lines)
in golang.org/x/sys. Additions to x/sys/windows with a clear 1:1 mapping from
the Windows API to the Go API can be accepted without proposal review.
Determining whether a change is a 1:1 mapping is up to the golang.org/x/sys/windows
maintainers. Any additional APIs, including methods on types that aren't
clearly reflected in the Windows API, must go through Go proposal review.
Adding new C-equivalent data structures to support those system calls.
Again, if in doubt, file a proposal.
Compatibility
Programs written for Go version 1.x must continue to compile and work with
future versions of Go 1.
The Go 1 compatibility document describes
the promise we have made to Go users for the future of Go 1.x.
Any proposed change must not break this promise.
Language changes
In 2018 we started a Go 2 process during which we may change the
language, as described on the Go
blog.
Language changes should follow the proposal process described here.
As explained in the blog entry, language change proposals should
address an important issue for many people,
have minimal impact on everybody else, and
come with a clear and well-understood solution.
Proposals should follow the Go 2 template.
See the Go 2 review minutes
and the release notes for
examples of recent language changes.
Design Documents
As noted above, some (but not all) proposals need to be elaborated in a design document.
The design doc should be checked in to the proposal repository as design/NNNN-shortname.md,
where NNNN is the GitHub issue number and shortname is a short name
(a few dash-separated words at most).
Clone this repository with git clone https://go.googlesource.com/proposal
and follow the usual Gerrit workflow for Go.
The design doc should follow the template.
The design doc should address any specific concerns raised during the initial discussion.
It is expected that the design doc may go through multiple checked-in revisions.
New design doc authors may be paired with a design doc "shepherd" to help work on the doc.
For ease of review with Gerrit, design documents should be wrapped around the
80 column mark.
Each sentence should start on a new line
so that comments can be made accurately and the diff kept shorter.
In Emacs, loading fill.el from this directory will make fill-paragraph format text this way.
Comments on Gerrit CLs should be restricted to grammar, spelling,
or proce
Read the full README on GitHubWhat Hacker News says
100 sourcesGo monomorphizes quite a lot, so that's mostly incorrect - it'd be relatively true for Java, for comparison, ignoring Graal. https://github.com/golang/proposal/blob/master/design/generi... there are only exceptions when you instantiate multiple different types that share an underlying type/layout, all other cases (including different types) are monomorphized. E.g. `type x struct{a int, b float32}` and `type y struct{b int, a float32}` share codegen, but if you even just swap the type order (float32 then int) they wouldn't.
The primitive generic atomics in the stdlib don't run into those details, so you really do get pretty much exactly the compiled code as what you'd write inline by hand:
>In particular, fundamentally different built-in types such as int and float64 are never in the same gcshape. Even int16 and int32 have distinct operati
Read the rest
ons (notably left and right shift), so we don’t put them in the same gcshape.
Ah the usual barrage of links from Go folks, luckily we have also come prepared.
> In three years of Go surveys, lack of generics has always been listed as one of the top three problems to fix in the language.
https://blog.golang.org/why-generics
> In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier.
https://github.com/golang/proposal/blob/master/design/go2dra...
And naturally Rob Pike's pearl,
> think the transition to getting polymorphism into the language through generics is has still got some years to work through there's still things that don't quite work right
https://youtu.be/yE5Tpp2BSGw?t=2134
In How Go detects struct copies with sync.noCopyThis idea that they just caved and added them due to pressure is a false narrative invented by detractors like yourself. Here is a timeline if you're interested:
2009 Go released.
June 2010 https://github.com/golang/proposal/blob/master/design/15292/...
Jan 2011 https://github.com/golang/proposal/blob/master/design/15292-...
March 2011 https://github.com/golang/proposal/blob/master/design/15292/...
Oct 2013 https://github.com/golang/proposal/blob/master/design/15292/...
Dec 2013 https://github.com/golang/proposal/blob/master/design/15292/...
April 2016 https://github.com/golang/go/issues/15292
Aug 2018 https://github.com/golang/proposal/blob/master/design/go2dra...
Aug 2018 https://github.com/golang/proposal/blob/master/design/go2dra...
June 2020 https://go.dev/blog/generics-next-step
Jan 2021 https://github.com/golang/go/issues/43651
Jan
Read the rest
2021 https://github.com/golang/proposal/blob/master/design/43651-...
Feb 2021 Proposal accepted.
March 2022 Ships in Go 1.18.
You could criticize Go for moving too slow. But I'm pretty happy with the way they landed. They definitely don't feel bolted-on.
While I have no experience with go, this seems like an interesting idea. Hackernews however isn't a great place to post this proposal if you want it to be implemented.
Maybe take a look at https://github.com/golang/proposal and if you want to share your proposal with hn, submit a link to the proposal here.
In Proposal: Throw as a Special Variable for Auto Error Propagation in GoI know they implemented an optimization back in go 1.13. Not sure if that will help.
https://github.com/golang/proposal/blob/master/design/34481-...
In The Defer Technical Specification: It Is Timethe most basic example was the declined proposal https://github.com/golang/proposal/blob/master/design/32437-...
Some people didn't like the "try" keyword it reminded them too much of exceptions, some people didn't like that they couldnt see a return inline (which was the purpose of the proposal in the first place).
it's not that there are no solutions. the main problem is the go team's insistence to have "one true way" (tm) of doing something and unfortunately this gap between people who want to see every return inline and people who want to see the clean solution separate from the error handling is not something that can be bridged by technical means. the only solution is to implement both ways and lets see which one wins.
In Lies we tell ourselves to keep using Golang (2022)> get monomorphized copies (not erased to "any") of each function for all concrete types used
That's not exactly true. You get one concrete function for all generic pointer types for instance.
Generic functions take a hidden paramater called a dictionnary, which is fairly similar to vtable, since it contains type information and pointers for all methods of the generic type that the function calls.
So methods on generic types are still performed through an indirection.
https://github.com/golang/proposal/blob/master/design/generi...
In Gio UI – Cross-platform GUI for GoJust wanted to note Go does only a partial monomorphization, only monomorhpizes for gcshapes and not for all types. This severely limits the optimization potential and adds a runtime cost to dispatch, at least in its initial implementation.
https://github.com/golang/proposal/blob/master/design/generi...
In Rust – Faster compilation with the parallel front-end in nightlyThe conclusion is pretty weird to me.
Go does rely on monomorphization for generics, just like C++ and Rust. The only difference is that this is an implementation detail, so Go can group multiple monomorphizations without worrying about anything else [1]. This form of hybrid monomorphization is being increasingly common, GHC does that and Rust is also trying to do so [2], so nothing special for Go here.
On the other hand, explaining variance as a lifted polymorphism is---while not incorrect per se---also weird in part because a lack of variance is at worst just an annoyance. You can always make an adapter to unify heterogeneous types. Rust calls it `Box<dyn Trait>`, Go happens to call it an interface type instead. Both languages even do not allow heterogeneous concrete (or runtime) types in a single slice! So variance has no use in both l
Read the rest
anguages because no concrete types are eligible for variance anyway.
I think the conclusion got weird because the term "subtyping" is being misused. Subtyping, in the broadest sense, is just a non-trivial type relation. Many languages thus have a multiple notion of subtyping, often (almost) identical to each other but sometimes not. Go in particular has a lot of them, and even some relation like "T implements U" is a straightforward record subtyping. So subtyping is indeed a red herring here. Given this, it is no surprise that the non-uniform value representation has the largest influence, and only monomorphization schemes and hetero-to-homogeneous adapters vary in this particular group.
[1] https://github.com/golang/proposal/blob/master/design/generi...
[2] https://rust-lang.github.io/compiler-team/working-groups/pol...
https://github.com/golang/proposal/blob/d661ed19a203000b7c54...
About five years too late, heh.
In Backward Compatibility, Go 1.21, and Go 2> I wonder: why not go further and say "there will never be a Go 2" in order to eliminate ambiguity about this?
They did, five years ago. Albeit with an “if”.
https://github.com/golang/proposal/blob/d661ed19a203000b7c54...
> If the above process works as planned, then in an important sense there never will be a Go 2. Or, to put it a different way, we will slowly transition to new language and library features. We could at any point during the transition decide that now we are Go 2, which might be good marketing. Or we could just skip it (there has never been a C 2.0, why have a Go 2.0?).
> Popular languages like C, C++, and Java never have a version 2. In effect, they are always at version 1.N, although they use different names for that state. I believe that we should emulate them. In truth, a Go 2 in the full sense of the word, in
Read the rest
the sense of an incompatible new version of the language or core libraries, would not be a good option for our users. A real Go 2 would, perhaps unsurprisingly, be harmful.
Fair criticism, though I do wonder if it'd really make that much of a difference. Go doesn't really monomorphize generics either, and would end up with an equally if not more expensive lookup for the correct generic function at runtime.
Some reading:
https://github.com/golang/proposal/blob/master/design/generi...
https://planetscale.com/blog/generics-can-make-your-go-code-...
In Defining interfaces in C++ with ‘concepts’ (C++20)As far as I can tell, the consensus for generics was "it will happen, but we really want to get this right, and it's taking time."
I know some people did the knee-jerk attacks like "Go sucks, it should have had generics long ago" or "Go is fine, it doesn't need generics". I don't think we ever needed to take those attitudes seriously.
> Will error handling be overhauled or not?
Error handling is a thorny issue. It's the biggest complaint people have about Go, but I don't think that exceptions are obviously better, and the discriminated unions that power errors in Rust and some other languages are conspicuously absent from Go. So you end up with a bunch of different proposals for Go error handling that are either too radical or little more than syntactic sugar. The syntactic sugar proposals leave much to be desired. It looks like people ar
Read the rest
e slowly grinding through these proposals until one is found with the right balance to it.
I honestly don't know what kind of changes to error handling would appear in Go 2 if/when it lands, and I think the only reasonable answer right now is "wait and find out". You can see a more reasonable proposal here:
https://github.com/golang/proposal/blob/master/design/go2dra...
Characterizing it as a "lack of vision" does not seem fair here--I started using Rust back in the days when boxed pointers had ~ on them, and it seemed like it took Rust a lot of iterations to get to the current design. Which is fine. I am also never quite sure what is going to get added to future versions of C#.
I am also not quite sure why Go gets so much hate on Hacker News--as far as I can tell, people have more or less given up on criticizing Java and C# (it's not like they've ossified), and C++ is enough of a dumpster fire that it seems gauche to point it out.
Not to detract from your general point, but I believe that this specific situation was addressed in Go 1.18's GC pacer rework: https://github.com/golang/proposal/blob/master/design/44167-....
In Generics can make your Go code slowerShowing the 15 most recent of 100 sources. Enable JavaScript to search and browse every indexed mention.