This technical blog post describes the source-level inliner tool in Go 1.26, advocating for developer autonomy and open-source code modernization. The content champions self-service API migration tooling and demonstrates how automation reduces repetitive labor, indirectly supporting developer agency and freedom of expression within the software engineering community. The post is educational and participatory in tone, though tracking without explicit consent and incomplete accessibility features slightly undermine its structural alignment with privacy and universal access principles.
If I follow, this isn't a compile time inline directive, it's a `go fix` time source transformation of client code calling the annotated function.
Per the post, it sounds like this is most effective in closed-ecosystem internal monorepo-like contexts where an organisation has control over every instance of client code & can `go fix` all of the call sites to completely eradicate all usage of a deprecated APIs:
> For many years now, our Google colleagues on the teams supporting Java, Kotlin, and C++ have been using source-level inliner tools like this. To date, these tools have eliminated millions of calls to deprecated functions in Google’s code base. Users simply add the directives, and wait. During the night, robots quietly prepare, test, and submit batches of code changes across a monorepo of billions of lines of code. If all goes well, by the morning the old code is no longer in use and can be safely deleted. Go’s inliner is a relative newcomer, but it has already been used to prepare more than 18,000 changelists to Google’s monorepo.
It could still have some incremental benefit for public APIs where client code is not under centralised control, but would not allow deprecated APIs to be removed without breakage.
Can't golang devs prioritize something like annotations or other attribute/metadata system instead of writing these in comments? I'm pretty sure this must have been raised a lot of times before, so just wanted to ask if there is/are any specific reason(s)?
Go designers distinguish between Go language as defined by Go spec and implementation details.
//go:fix is something understood by a particular implementation of Go. Another implementation could implement Go without implementing support for //go:fix and it would be a fully compliant implementation of Go, the language.
If they made it part of the syntax, that would require other implementations to implement it.
yeah this is the part that got me excited honestly. we're not google-scale by any stretch but we have ~8 internal Go modules and deprecating old helper functions is always this awkward dance of "please update your imports" in slack for weeks. even if it doesn't let you delete the function immediately for external consumers, having the tooling nudge internal callers toward the replacement automatically is huge. way better than grep + manual PRs
recover()'s semantics make it so that "pointless" use like this can be inlined in a way that changes its semantics, but "correct" use remains unchanged.
Yes, maybe some code uses recover() to check if its being called as a panic handler, and perhaps `go fix` should add a check for this ("error: function to be inlined calls recover()"), but this isn't a particularly common footgun.
Because these are instructions for users for making tool-assisted changes to their source code, not a behavior that exists at runtime (or even compile time). A new syntax wouldn't make sense for it.
For other things, like `//go:noinline`, this is fair criticism. `//go:fix inline` is quite different in every way.
I'm not sure what all of the hazards are, but I could imagine a language (or a policy) where public APIs ship with all of the inline fix directives packaged as robust transactions (some kind of "API-version usage diffs"). When the client pulls the new API version they are required to run the update transaction against their usage as part of the validation process. The catch being that this will only work if the fix is entirely semantically equivalent, which is sometimes hard to guarantee. The benefits would be huge in terms of allowing projects to refine APIs and fix bad design decisions early rather than waiting or never fixing things "because too many people already depend on the current interface".
Content champions participation in scientific and cultural life of software engineering community. Describes open-source tooling that enables broad participation in code modernization and technical culture. Post itself is technical education accessible to developers.
FW Ratio: 50%
Observable Facts
Post documents technical innovation in open-source Go ecosystem.
Describes 'self-service' model enabling any package author to create modernizers, democratizing participation.
Content is published as blog post making technical knowledge publicly available.
Inferences
Self-service inliner tool model promotes democratic participation in technical culture.
Public documentation enables broader developer community to engage in and benefit from scientific/technical advancement.
Partial accessibility (77% alt text) somewhat limits participation by some users with disabilities.
Content advocates for open-source software modernization and API migration tooling. Promotes developer freedom through automated code transformation and transparency in tool design. Indirectly supports expression and information-sharing within technical community.
FW Ratio: 50%
Observable Facts
Post explains go fix command enabling 'self-service modernizers' for package authors.
Author (Alan Donovan) clearly credited; post date provided.
Content describes technical mechanisms for code transformation in open-source Go ecosystem.
Inferences
Emphasis on self-service tooling and automation supports developer agency and expression.
Public documentation of tool design promotes transparency in software modernization practices.
Tracking without consent slightly mitigates structural support for information privacy.
Content indirectly supports labor rights through developer productivity and autonomy. Describes tools that reduce repetitive manual work and enable 'self-service' refactoring, potentially reducing drudgery and increasing workers' control over their tools and workflow.
FW Ratio: 50%
Observable Facts
Post describes automation of code migrations, reducing manual refactoring burden on developers.
Mentions Google use case: 'robots quietly prepare, test, and submit batches of code changes' across monorepo, eliminating millions of deprecated calls.
Inferences
Automation reduces repetitive manual labor and increases developer agency over workflow.
Self-service tooling model empowers package authors and individual developers with control over modernization process.
No direct structural engagement with participation in cultural or scientific life. Accessibility features (77% alt text, lang attr, skip nav) partially support inclusion.
Google Analytics and GTM trackers active; no cookie consent banner. Tracking modifier: 0; consent modifier: 0. Net neutral signal on privacy protections.