Go Blog
blog.golang.org · Company blog · on HN since 2010
The official Go team blog, with posts on language features, tooling, the runtime, and design decisions.
What HN saysCommenters call the posts well written and cite them for topics like Go modules, UTF-8 strings, and the Go fonts.
529HN people shared it
406linked it in comments
258stories submitted
21Kstory points
3 months agolast shared
2010people per year2026
Most-shared posts
- 1Getting to Go: Garbage collection and runtime issues36 people · 369 points · first shared 2018 · 131 comments on HN
- 2Errors are values28 people · 147 points · first shared 2015 · 135 comments on HN
- 3Concurrency Is Not Parallelism (2013)24 people · 82 points · first shared 2013 · 49 comments on HN
- 4Profiling Go Programs22 people · 3 points · first shared 2013 · discussion on HN
- 5Defer panic and recover19 people · first shared 2013
- 6Generating code17 people · 156 points · first shared 2014 · 85 comments on HN
- 7Strings, bytes, runes and characters in Go16 people · 76 points · first shared 2013 · 35 comments on HN
- 8Go fonts15 people · 295 points · first shared 2016 · 170 comments on HN
- 9Go GC: Prioritizing low latency and simplicity14 people · 217 points · first shared 2015 · 137 comments on HN
- 10Go Concurrency Patterns: Pipelines and cancellation13 people · 327 points · first shared 2014 · 32 comments on HN
- 11Using Go Modules13 people · 302 points · first shared 2019 · 118 comments on HN
- 12Introducing the Go Race Detector13 people · 141 points · first shared 2013 · 40 comments on HN
- 13Defer, Panic, and Recover - Go blog13 people · 42 points · first shared 2010 · 12 comments on HN
- 14The Go gopher13 people · 8 points · first shared 2014 · 2 comments on HN
- 15Toward Go 211 people · 746 points · first shared 2017 · 640 comments on HN
What HN people wrote when they linked it
pm90 · 2015-10-19
Effective Go is a great intro: https://golang.org/doc/effective_go.html
Also, check out the blog posts for more information on specific topics: http://blog.golang.org/. They are really well written.
37ef_ced3 · 2021-06-28
Since 2017 I have used the Go (Golang) Monospace TrueType fonts:
https://blog.golang.org/go-fonts
Truly excellent
jd3 · 2021-01-21
I do love the simplicity of Go's UTF-8[0] approach, though this did also burn me when I was first learning the language and did not really understand the implication of it.
I translated an x-face encoder from js to go for one of my introductory projects and initially couldn't get the correct output from `b64.StdEncoding.EncodeToString` due to the fact that x-face strings are single-byte ASCII ISO-8859-1 encoded[1].
[0]: https://blog.golang.org/strings
[1]: https://stackoverflow.com/questions/43461679/escaping-of-hex-values-in…
djeiasbsbo · 2020-11-06
Dependency management is better now with Go Modules. Not as great as e.g. with cargo in the Rust ecosystem but definitely an improvement.
https://blog.golang.org/using-go-modules
cap10morgan · 2020-09-10
I see a lot of comments in here about the v2+ rule’s reason for existing being to allow importing multiple major versions of a module. That’s not it at all. As the blog post (which was easily Googled by me and explains things quite well IMO) states: “If an old package and a new package have the same import path,
the new package must be backwards compatible with the old package.”
They’re trying not to break compatibility until a downstream developer explicitly opts in to that breakage. The simplest way to do that is to give the module a new name. And the simplest way to do that is append the major version to the name.
Here is the post: https://blog.golang.org/v2-go-modules
For more background on this principle, I recommend Rich Hickey’s Clojure/conj keynote “Spec-ulation” from 2016: http://blog.ezyang.com/2016/12/thoughts-about-spec-ulation-rich-hickey…
edwintorok · 2020-07-23
Since we're onto recommendations, I've been using 'Go Mono' for a while:
https://fontlibrary.org/en/font/go-mono
https://blog.golang.org/go-fonts
Wish the 'Recursive' font had a 'Slab-Serif' slider too, would've been interesting to compare.
gen220 · 2020-06-23
Rick Hudson gave this excellent keynote on some of the "recent" (as of 2018) improvements and guiding principles for Go's GC, if you're interested in the nitty-gritty. https://blog.golang.org/ismmkeynote
He outlines the SLOs for the garbage collector, with the motivation that this SLO impacts the SLOs/time budget of every application built with Go. They key metrics are "share of CPU used for GC", heap sizes, latency and frequency of pauses, and scaling favorably with go-routine allocations.
HALtheWise · 2019-12-15
It's fundamentally difficult to compare them, because the features of the language itself change the workload the GC faces in a typical program. For example, Java boxes almost all values, so can't store very much on the stack. That means that conventional Java programs (typically) generate many more short-lived heap allocations than Go programs.
For more, see the excellent blog post here: https://blog.golang.org/ismmkeynote
tyingq · 2019-12-01
Interesting, as it is definitely the classic 3270/5250 font. Your friend must of specified a very "not 3270" font for their terminal emulator.
The most unixy iconic serif monospaced font I can think of would be Sun's Gallant Demi: https://images.app.goo.gl/Nx2wzRvY71DczMVdA
Or more recently, the Golang monospaced fonts: https://blog.golang.org/go-fonts
zemo · 2019-09-22
Go is honestly probably not a great language for game development for other reasons but the GC could likely clear that goalpost. https://blog.golang.org/ismmkeynote
benhoyt · 2019-09-21
In particular I know that Go's GC is optimized for very low latency (rather than throughput), and is not a stop the world GC. So I'm wondering why it doesn't work for games? Are the pauses still too high for games, or is he missing something? Benchmarks or concrete results in Go would be great here.
Edit: specifics from https://blog.golang.org/ismmkeynote - Go hugely improved GC latency from 300ms before version 1.5, down to 30ms, then again down to well under 1ms but usually 100-200us for the stop the world pause. So I guess it is stop the world but the pauses seem ridiculously small to me. They guarantee less than 500 microseconds "or report a but", which seems more than fast enough for game framerates (16ms for 60Hz frames). Am I missing something?
ereyes01 · 2019-09-05
Go's pprof comes with a great memory (and cpu + more) profiler: https://blog.golang.org/profiling-go-programs
atombender · 2019-08-20
It's worth noting that Go is getting its own registry system soon, the Go Module Index [1].
[1] https://blog.golang.org/modules2019
mcv · 2019-05-22
That sounds logical, and I'm no expert on either Go or systems programming, but I've often heard of Go being referred to as a systems programming language, and on their own blog[0] they list it in third place at 37% as popular use of the language. Well after web development, admittedly, so apparently it is more a web development language than a systems programming language. I was clearly wrong on that part.
[0] https://blog.golang.org/
kardianos · 2019-05-11
Go's GC is not currently generational. As others have mentioned, Go gives you more control over memory which helps considerably.
If you want to know more about the current progress, there is a great presentation -> blog here: https://blog.golang.org/ismmkeynote
And you can see the most recent generational GC code here:
https://go-review.googlesource.com/c/go/+/137482
Though my guess is it won't get merged into mainline for Go1.13 as it is already in code freeze.
aksx · 2019-04-22
>The best parts of rust's error handling are the try!() macro (aka `?`),
Go's way of providing try!() macro is less magical but almost as useful.[1]
> From/Into error types allow the compiler to wrap types or convert between error types
error is an interface in Go which can be easily cast/checked for the underlying type.
> Go's error handling is pretty primitive
I wouldn't call it primitive, I would call it simple. I like the comparison i read on a blog on HN.
Rust is the 'new' C++ and Go is the new C
[1] https://blog.golang.org/errors-are-values
hu3 · 2019-03-30
Comparing Go's GC to one of the many specialized fine-tunned Java GCs is pointless, I find.
I'm sure you're also aware that recent Go's GC pauses are sub millisecond for most use cases:
"We now have an objective of 500 microseconds stop the world pause per GC cycle." - 2018 Go team
https://blog.golang.org/ismmkeynote
My personal experience with microservices is to expect STW pauses in the 350 microsecond range. The best part is that it requires zero tunning or developer's attention while still being light on memory usage. Can't say the same for Java's default GC.
cygned · 2019-01-12
Recently found the Golang fonts.
https://blog.golang.org/go-fonts
Monospaced with serifs - totally blew my mind. I am using it since then and it is the best font for me I have tried so far.
pdw · 2019-01-10
The Go Mono font is a modern iteration of that concept. I love it. https://blog.golang.org/go-fonts
jashmatthews · 2018-10-05
https://blog.golang.org/ismmkeynote is worth a read. Apparently, the write barrier overhead makes it not really worth it for the Go ecosystem to adopt a generational or moving GC. I think WebKit also switched to a non-moving GC, but retained bump-allocation into empty pages.
attractivechaos · 2018-09-09
Which versioning scheme to use doesn't matter. What matters is how long you promise to keep a language "stable". Java and javascript have gone through many major versions, but the core of the language is largely stable. The same will be true to golang. Read their plan [1], the paragraph starting with "Go 2 must also bring along all the existing Go 1 source code". That is promised backward compatibility. There have been breaking changes in Perl5 (so it is not following semver), but most of the changes were minor and little user code was affected. Python 2=>3 is a disaster. If Julia goes through a dramatic change like that in 5 years, it will be worse.
[1] https://blog.golang.org/toward-go2
zippoxer · 2018-05-26
One of Go's features is fast compilation, which wouldn't have been the case if it used LLVM.
> a GC which is competitive with JVMs from 15 years ago
I don't know where you got this impression, but it's absolutely wrong. Go's garbage collector is excellent. It has sub-millisecond pauses [1] (for multi-gig heaps), and it mostly runs in parallel to the application.
You might be referring to Go's old GC, which was dropped when the current was introduced. [2]
[1] https://groups.google.com/forum/?fromgroups#!topic/golang-dev/Ab1sFeoZ…
[2] https://blog.golang.org/go15gc
electricslpnsld · 2018-05-25
> The listener-funded radio station that runs the archive, WFMU, is the single greatest radio station in the world.
Little known fact: the Go gopher mascot was originally a WFMU commission [1].
[1] https://blog.golang.org/gopher
ynezz · 2017-12-07
Source: https://blog.golang.org/toward-go2
> I don't believe Go 2.0 will ever happen.
"Once all the backwards-compatible work is done, say in Go 1.20, then we can make the backwards-incompatible changes in Go 2.0. If there turn out to be no backwards-incompatible changes, maybe we just declare that Go 1.20 is Go 2.0."
So yeah, Go 2.0 might not even happen.
> So far that page looks like when our government puts out "work commission" for any ongoing problem people complain about.
I would love if my government would take some inspiration from such projects, namely from this:
"We did what we always do when there's a problem without a clear solution: we waited."
jadeklerk · 2017-11-05
I found the original golang blog to be a fantastic resource on the topic: https://blog.golang.org/profiling-go-programs
crawshaw · 2017-11-04
One good example is untyped constants. They form a large extension to the type system only present at compile time. It is a good example because there is an excellent blog post describing them in detail: https://blog.golang.org/constants
In particular note the difference between
const hello = "Hello, 世界"
and
const typedHello string = "Hello, 世界"
one of these can be assigned to named string types, the other cannot.
As a user of Go I find untyped constants to be extremely useful. They almost always do what I want without surprise. Implementing them however, is not trivial.
A tricker example is embedding. It adds a lot of complexity to the type system. As a user, it can be a bit surprising, but I admit it is very useful.
sethammons · 2017-10-06
The first is doing the tour at golang.org, then reading Effective Go at https://golang.org/doc/effective_go.html. There are lots of good reads at the golang blog, such as https://blog.golang.org/organizing-go-code. I really enjoy Go, and hope you do too!
arrakeen · 2017-09-05
i decided to give Go Mono[1] a chance when they released it almost a year ago and i love it! and to the HN commenter who said i wouldn't last a week with the font, i thumb my nose
[1] https://blog.golang.org/go-fonts
chris_st · 2017-08-19
I've been using Go for a while, and am frankly amazed at the quality of the tooling.
I'll add something others haven't mentioned... the profiler produces an absolutely amazing graph of the run-time call tree[0]. This makes it incredibly easy to not only see where the code is spending its time, I can easily the context, and where else time is being spent. I recently sped some code up (5x!) using this.
0: https://blog.golang.org/profiling-go-programs
old-gregg · 2017-02-16
1.7 release was great for finally addressing the issue of ever-growing size of produced binaries. [1] Moreover, some additional improvements were promised in 1.8 which I was looking forward to.
But after upgrading to 1.8 I am now observing 3-4% binary increase vs 1.7, so the trend is again reversed back to fatter binaries. :(
[1] https://blog.golang.org/go1.7-binary-size