> Yet one would hope for a bit terser syntax and language supported stack traces, 11 years after launch.
The Go team tried, but the community shot it down.
Your link was the first proposal, and this was the second proposal: https://github.com/golang/proposal/blob/master/design/32437-...
In Eleven Years of Gogolang
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
8 sourcesThings I like about Go (in this order):
* useful, not shiny. No new framework every year, just for the sake of it. An actually readable spec. Changes heavily thought through before being introduced. A programming language isn't a place to move fast and break things, as changes often cannot be undone.
* Readable code. You can figure out what a piece of code does pretty easily. Even if you can't do so at first glance, you know where to look next.
* Simplicity. I personally like having full understanding of things. This applies both to the language itself, as well as to the tools (go test, go mod, go generate etc). This is pretty subjective.
* The formatter. As a screen reader user, aligning things with spaces so that they would form nice little tables is a hard task for me. I'm happy I don't have to do so.
* Compiling programs as single, s
Read the rest
tatic binaries, assets included.
Some small things I don't like (also in that order):
* No try macro[1]. IMO try was a better solution than exceptions, and I found the arguments against it not that compelling.
* Overrelliance on struct tags, which shouldn't exist at all IMO. I don't want to couple my business logic, storage and view layers. Options for i.e. JSON should be specifiable at call time.
* No generics, or, even better, zig-like comptimes. They're simpler and more powerful, though they wouldn't probably neatly fit into go2.
Overall, I'd give go about 8.5/10.
[1] https://github.com/golang/proposal/blob/master/design/32437-...
File System Interfaces for Go – Draft Design
1 points · Open discussionDefers can happen in a loop, so you need a stack for correctness. This change is that the compiler will now automatically inline the defer-ed call so they appear much the same as a direct call at the end of a function if they happen at most once.
The full design doc is here: https://github.com/golang/proposal/blob/master/design/34481-...
> Go 1.13 implements the defer statement by calling into the runtime to push a "defer object" onto the defer chain. Then, in any function that contains defer statements, the compiler inserts a call to runtime.deferreturn at every function exit point to unwind that function's defers.
> We propose optimizing deferred calls in functions where every defer is executed at most once (specifically, a defer may be on a conditional path, but is never in a loop in the control-flow graph). In this optimization, the c
Read the rest
ompiler assigns a bit for every defer site to indicate whether that defer had been reached or not. The defer statement itself simply sets the corresponding bit and stores all necessary arguments in specific stack slots. Then, at every exit point of the function, the compiler open-codes each deferred call, protected by (and clearing) each corresponding bit.
Seems like this has been merged:
https://github.com/golang/go/issues/35112
https://github.com/golang/proposal/blob/master/design/35112-...
In Distributed cache and K/V store in Go. Embeddable or independent servicepanic is a built-in and so was try:
https://golang.org/pkg/builtin/#panic
"The panic built-in function stops normal execution of the current goroutine. [...]"
It's not among the list of keywords: https://golang.org/ref/spec#Keywords
"Q: Why is try a built-in?
A: By making try a built-in, there is no need for a new keyword or operator in Go. Introducing a new keyword is not a backward-compatible language change because the keyword may conflict with identifiers in existing programs. Introducing a new operator requires new syntax, and the choice of a suitable operator, which we would like to avoid. Using ordinary function call syntax has also advantages as explained in the section on Properties of the proposed design. And try can not be an ordinary function, because the number and types of its results depend on its input"
https://github.com/
Read the rest
If you look at the questionnaire[1] they ask for new changes, it's clear they still want a justification, and a design, for new proposals. And that proposals which "state a problem rather than a solution" will be rejected.
It's just that they've been convinced that generics are justified. And they have concrete proposed solutions under evaluation.
[1] https://github.com/golang/proposal/blob/master/go2-language-...
In Proposals for Go 1.15In theory, every runtime (including JVM or even C!) implementation could be implemented with arbitrary user-space preemption, but it’s rather expensive, incurs a lot of overhead. So, languages/platforms that (to some degree) optimize for performance (definitely C, but also Golang, JVM) avoid that.
In particular, tight loops suffer - to support preemption, basically in every loop you need an extra condition, to check whether enough time has passes for the task to be interrupted. This turns out to be expensive enough that basically your language is useless for any kind of mathematical computations (all vector & matrix math and a lot of statistics is full of loops within loops).
Golang in particular dealt with this issue extensively, not just because of starvation, but also because of GC - in order to enable garbage collection of global obje
Read the rest
cts, all threads need to be paused and their local variables & stacks snapshoted. Doing that efficiently is hard. I think they were trying to make threads arbitrarily preemptable with OS signals, but that requires extreme care with implementation (you need to know where local variables are stored at every instruction!) and is not portable (no signals on Windows).
E.g. https://github.com/golang/proposal/blob/master/design/24543-...