//go:fix inline and the source-level inliner

This is very handy for internal rewrites too.

I love the details on how the source inliner works, but I think there's a subtle point that is made but could be emphasized more: When you make a breaking API change, it's already considered a best practice to rewrite the old implementation to use the new one (if you can), since then you don't have to maintain parallel implementations at the same time. With a good source inliner, that work that you already wanted to do now gives you, for free, a codemod for migrating callers!

This is an elegant solution because —

• it uses a refactoring DSL that users already know!
  • when I wrote such tools, I would try to use a declarative "before"/"after" template system with placeholders so that users didn't have to memorize e.g. bespoke syntax tree APIs
    • but even then, this is clearly superior from a UX perspective for 95% of cases
  • this, of course, is at the expense of the implementer having to write complex, reliable, general-purpose inlining logic...
    • somewhat the opposite of the "worse is better" ethos that pervades other aspects of Go's design?
• it's "eventually consistent" and permits distributed development to continue even while the refactoring is being "applied"
  • hence you can largely avoid so-called "atomic" refactors breaking a bunch of work in progress
  • but still enforce forward progress on active development branches!
  • this includes enabling Go's backward-compatibility guarantee, as per the article — that's "distributed" development too!

Very cool! I wonder if such tools or extensions to the analyzer exist for Rust...? 🤔