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 slowergolang
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 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:01:12 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
11 sourcesIt’s not a satisfying answer, but the truth is that there just isn’t that much Go code out there suffering from a lack of the kind of basic generics being introduced. It exists, but it’s not the norm.
Instead, what is likely to happen is, a lot of problems that generics can be applied to, they more often will be, simply because the option is on the table, regardless of whether it really improves anything. Go taught me to stop worrying and trust the For loop, and now we’re probably going to have dozens of utility libraries with Map and Reduce routines that people will use for extremely simple loops that don’t need them, probably resulting in slower code that takes longer to compile that needs a slower and more complicated optimizer to make up for it. In my opinion, the antithesis of what makes Go great.
Not saying generics is all bad, or t
Read the rest
hat reduce is bad, or anything like that. But once a programming language has a new way to do something, you can be damn well sure people will use it, often even to their own disadvantage. Go doesn’t have pattern matching control flow, so the best degree of soundness you can pull out of an Optional type is ugly visitor-pattern type interaction. And yet, I’m worried routines will superfluously return Optional types anyways, just because you can, even though it’s not really any better than just returning a type and a boolean.
And yes. Actual code that actually needs generics for real will benefit, undeniably. Data structure and generic algorithm implementations will benefit greatly. The ugly sort package can finally be cleaned up. That’s great. But, most Go programs simply aren’t suffering from a lack of basic generics. Operative words: most, and basic generics. Many programs simply don’t need any data structures other than a basic growable vector type and a basic hashtable, and Go has both and they are built-in and work generically. Yet the more complex problems that C++ templates and Rust generics solve will probably not be aided at all by Go generics, which are simply much more limited in scope.
And despite that, this is quite an increase in compiler complexity. I know many are thinking “how hard could it be? Tons of languages do it today”—but Go isn’t really like all of the other languages. The simpler compiler is a huge benefit to the compiler and the whole ecosystem. Arguably, Go’s simplicity enabled them to experiment with things that wouldn’t be very easy to do in other languages, with regards to its GC and threading model. They’ve got it figured out of course, but it really isn’t a simple walk in the park. Any single aspect has a lot going on:
https://github.com/golang/proposal/blob/master/design/generi...
My hope is that the relatively mature ecosystem of Go will somewhat encourage people to keep their code simple and use generics sparingly, but with such a major shift in the language it’s hard to imagine what is “idiomatic” won’t change over time. I feel Go’s brutalist simplicity is its strong point and that it will just be an inferior option if you try to write code in it like C++ or Rust.
Of course… we’ll see.
Go is not quite doing this level of expansion: https://github.com/golang/proposal/blob/master/design/generi...
In particular, a single expansion is shared for all pointer types.
In Go 1.18I thought this was something like traits, but it goes way beyond that.
Sub-dictionaries are described here: https://github.com/golang/proposal/blob/master/design/generi...
It looks like the compiler needs to walk down the entire call tree from the top-level generic and then compute new dictionaries for each called function. Since the compiler may not know the entire call tree, it may have to build nested dictionaries.
Wacky stuff!
In How generics are implemented in Go 1.18How generics are implemented in Go 1.18
288 points · Open discussionHow generics are implemented in Go 1.18
1 points · Open discussionProposal: Headings, lists, and links in Go doc comments
3 points · Open discussionregions have generations. its the same concept just partitioned to make the working sets smaller.
there isn't anything fundamentally wrong with golangs GC. attempting to apply the solutions for the JVM to golang is fundamentally flawed and ignorant.
the languages have fundamentally different approaches to memory allocations. and the reasons behind the JVM implementations simply do not exist in golang.
the new pacer is in the works to attempt addressing many of the edge cases. https://github.com/golang/proposal/blob/master/design/44167-...
you seem to lack fundamental understanding of what the actual issues in the golang runtime are with relation to its GC.
In Large-scale, semi-automated Go GC tuningWeird to not see any references to https://github.com/golang/go/issues/48409 / https://github.com/golang/proposal/blob/master/design/48409-...
There's been a lot of back-and-forth on how to improve the tuning situation in go. See https://github.com/golang/go/issues/42430. It seems like Michael Knyszek will be doing something about it for go 1.19.
In Large-scale, semi-automated Go GC tuningI really hope that they will release this as a library. We're having the exact same challenges running Go in production.
The biggest challenge with Go in production is that, as the article points out, Go doesn't have a maximum memory setting that can be used to tune the GC. If you run Go with a memory limit on Kubernetes, it's common for it to simply run out of memory rather than using the limit for backpressure.
This is kind of surprising, since Go is so entrenched in the Kubernetes world (and both Docker and Kubernetes are written in Go). It's possible that Google itself doesn't develop that much stuff in Go, and that the Go team doesn't have a huge incentive to innovate in this area.
There have been a few attempts at improving heap management, including an aborted attempt at respecting ulimit [1], a promising implementation of a SetMax
Read the rest
Heap() function [2], and a propsoal for dealing with backpressure [3], but these projects have mostly failed to get proper traction. It's a complex problem that needs a cohesive solution.
Fortunately, there is now a proposal [4], which has been accepted, to add a soft limit to Go, which has a more thought-through design [5], though I'm not sure if it's being actively worked on yet.
I'm also not sure if that proposal, when implemented, will make the Uber approach redundant, or if these are in fact complementary. If Uber could open-source their library, it might be a good solution until Go itself has better GC management.
[1] https://github.com/golang/go/issues/5049
[2] https://github.com/golang/go/issues/16843
[3] https://github.com/golang/go/issues/29696
[4] https://github.com/golang/go/issues/48409
[5] https://github.com/golang/proposal/blob/master/design/48409-...
It was a design goal that monomorphization should always be possible, but Go will not be monomorphizing generic functions to save on compile time / binary bloat (it will instead use GCShape stenciling, see below). I suspect future releases will be smarter and monomorphize some functions for performance, but that's really up to the Go team.
Initial implementation strategies considered for generics:
https://github.com/golang/proposal/blob/master/design/generi...
https://github.com/golang/proposal/blob/master/design/generi...
https://github.com/golang/proposal/blob/master/design/generi...
In Compiling a Go program into a native binary for Nintendo Switch