HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
kstenerud
go
Go2019–2025
kstenerud / go

go

The Go programming language, modified to emit warnings

3Distinct people
22Mentions
0Explicit recommenders
21GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

The Go programming language, modified to emit warnings

GitHub

Where it is used

No documented product use has been verified yet.

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

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 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 year22 dated mentions

Observed mentions: 2019-04-18 17:01:57 UTC to 2025-07-12 00:11:56 UTC.

0369122019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 12 mentions; 3 submissions, 9 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC1239
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC909
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101

What Hacker News says

22 sources
I feel like that example doesn't fit except in the specific case that the language designer restricts the usage of null in a way that reduces the overall expressiveness and power of the language. Whereas (but one example) the operators provided by Kotlin don't do that. Obviously how exactly you structure a particular end result is going to involve lots of fuzzy tradeoffs. My point wasn't about such nuance but rather the sort of reasoning that leads the the dismissal of an entire feature (in this case proper macros) on the basis of saving developers from themselves. There should be (at least IMO) a clear delineation between a language design that makes it possible to do things in a sensible manner versus the realm of style guides, linters, and pre-commit hooks that enforce restrictions intended to maintain sanity on large projects. I shoul
Read the rest
dn't feel compelled due to deficiencies in the design of the language to reach for constructs like goto but those constructs should still be there if I have a need for them. People shouldn't feel compelled to waste time patching their tools to work around the opinions of the designers being forced on them. [1][2] That said, it would be nice if compilers themselves universally provided native linting facilities, possibly even enabled by default. [1] https://github.com/kstenerud/go [2] https://github.com/tpope/heroku-fucking-console
In Flix – A powerful effect-oriented programming language
What the go team fails to realize is that they haven't actually reduced complexity in their design of go; they've simply MOVED it. And it's been moved in unintuitive ways as they've painted themselves into corners that should have been avoidable with some careful planning. We now have: - magic file names - magic directory names - magic comments - magic env vars - API design requires gymnastics and juggling since recursive imports are disallowed - A ton of useful code in the standard library remains unlayered and unexposed for no good reason (pprof, for example) - Requiring full paths rather than relative imports complicates everything when you're fetching it from a different source location (replace directives and magic ENV vars). - Slice implementation means that you need to do double pointer storage to keep track of the same slice from
Read the rest
multiple places - Creating arrays with a dynamically defined length is horribly overcomplicated - Their policy on warnings and instead calling every little thing an error is terrible and wastes a ton of developer time. - Lack of runtime const value support is just sloppy. - Why do go source files even need a package declaration? It serves no useful purpose since the compiler already knows enough to spit out an error if you get it wrong. - Refactoring across packages is nearly impossible to automate because there's no way to declare adherence to an interface. - No importing of test code from other test code (which means that the import code in the compiler has increased complexity to enforce this silly rule). - Stack overflows are STILL impossible to track down (after a DECADE!) because it only prints the top of the stack, which is useless in such a case. - Linting is too opinionated and is all-or-nothing. ------------------ I could go on. I really wanted to like go, and many parts of it do actually feel nice. But even after a decade it's a huge mess. I've spent more time writing workarounds for go than for any other language in my 25 year career. Hell, I even modified the damn compiler out of frustration! [1] [1] https://github.com/kstenerud/go#the-go-programming-language
In Keeping your Go modules compatible
I maintain a modified compiler (https://github.com/kstenerud/go/blob/master/README.md#the-go...) that can issue warnings instead for unused things. I use it as my daily driver for go development. main.go: package main import "fmt" func main() { var start int = 1 breakOuter: // for x := start; x < 10; x++ { for x := 3; x < 10; x++ { for y := 0; y < 10; y++ { result := y * 10 + x // fmt.Printf("Result: %d\n", result) // if result == 42 { // fmt.Printf("Breaking") // break breakOuter // } } } } Building: $ go build # example ./main.go:3:8: imported and not used: "fmt" ./main.go:8:5: label breakOuter defined and not used (compilation fails)
Read the rest
$ go build -gcflags=-warnunused # example ./main.go:8:5: Warning: label breakOuter defined and not used ./main.go:3:8: Warning: imported and not used: "fmt" ./main.go:6:9: Warning: start declared and not used ./main.go:12:13: Warning: result declared and not used (compilation succeeds)
In Diving into Go by building a CLI application
Go with warning flag patch also upgraded to 1.14: https://github.com/kstenerud/go#the-go-programming-language The warning flag patch allows you to do: go build -gcflags=-warnunused go test -gcflags=-warnunused which causes the compiler to only warn about unused things instead of stopping the build: $ go test -gcflags=-warnunused # github.com/kstenerud/go-describe ./describe_unsafe.go:8:2: Warning: imported and not used: "fmt" ./describe.go:329:2: Warning: isInUnsignedArray declared but not used ... PASS ok github.com/kstenerud/go-describe 0.002s I use this when debugging or for exploratory coding.
In Go 1.14 release notes
I'm still using it daily, and I think it's a "nicer C", perhaps sometimes even a "nicer C++" or "nicer Java" in a few ways. But I agree that as a general purpose language it's definitely lacking. No other language has inspired me to fight against its design and philosophy or overcome its deficiencies as much as go has ([1] [2] [3]). But for many purposes it's "good enough", and at least it's simple enough to dig around in the guts when I have to. [1] https://github.com/kstenerud/go [2] https://github.com/kstenerud/go-describe [3] https://github.com/kstenerud/go-subvert
In The Zen of Go
Go's tooling is very nice compared to most other dev technologies, and the source is quite hackable as well. I made a 1-commit modification to the compiler that adds a flag -warnunused to make it stop failing on unused imports or variables [1], and it was remarkably simple to do in the go src tree. Plus, it's super easy for other people to use. Just check out the modified source, make.bash, and you're done in less than a minute of compilation! I may not agree with some of their philosophies, but the tooling is nice! [1] https://github.com/kstenerud/go
In Go's Tooling Is an Undervalued Technology
It's explained in the use case: https://github.com/kstenerud/go#use-case Use Case The use case for warnings is the exploratory development or debugging phases, where you really don't care about leaving unused things lying around for the time being (for example, temporarily commenting something out), and would rather that the compiler just got out of your way until you've got something ready to compile normally and commit. Usage go build -gcflags=-warnunused somefile.go go test -gcflags=-warnunused When you're done with your exploratory/debugging phase, simply build or test without the flag: go build somefile.go go test Compiling without the flags will fail on unused things as normal.
In Go compiler internals: Adding a new statement to Go

Showing the 15 most recent of 22 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.