Codebase Refactoring with Go
I think the proposed alias has true merit in Go as has been shown by Russ Cox and in other places. What I&#x27;m a bit confused about is why it&#x27;s sold as a transitionary tool but implemented as a feature.<p>If it&#x27;s so easy and clean to use it may become a misused feature, causing developers to write &quot;temporary&quot; code that just lingers around forever because it&#x27;s more convenient to let it be than to actually move to the new API. I&#x27;d draw parallels with imports in Go versus imports in Python. I would wager that a great majority of Python repos out there have lingering imports in some module that doesn&#x27;t need to be there. But in Go I can guarantee that there are 0% unnecessary imports.<p>For example, the declaration could be obvious that this is for compatibility as opposed to a feature:<p>legacy const FUN_THINGS =&gt; funner.Things<p>Also, when compiling a package using the FUN_THINGS constant you&#x27;d be warned:<p>.&#x2F;main.go:10: using legacy alias: &quot;clowns.FUN_THINGS&quot; has moved to &quot;funner.Things&quot;<p>These small things would help prod developers to actually fulfill the transition as opposed to letting it linger.