Hacker News Reader

The main point of the article to me is "adding fields to Go structs is a breaking change" since your users could be using implicit struct initializer syntax, which will cause a compilation error. They have listed other points too, but I think this one can be highlighted.

View on HN

Using the unkeyed initializer syntax is discouraged anyhow: https://golang.org/cmd/vet/#hdr-Unkeyed_composite_literals

Unkeyed syntax also doesn't work for a struct in another package with at least one private field.

One common exception is a vector type that isn't expected to change--RGBA, XYZ, LatLon, etc.

The issue is that even if you only consider keyed initializers, adding fields is a breaking change, strictly speaking. I tried making clear that I use the compatibility guarantee as a basis in the introduction and I mention this exception more thoroughly in the section about adding fields.

Reply on news.ycombinator.com