> The compiler will always support old code written against older editions, but the language can still introduce breaking changes in newer editions. Developers can either opt in to new editions and migrate their code, or do nothing, and things continue to work fine. There is seamless/transparent interoperability.
This is exactly what the GODEBUG scheme described in the article is intended to allow.
The Go approach does indeed seem to enable similar functionality. Although I'm not quite sure I understand how the individual settings and the module level version declarations compose, and how much complexity that introduces.
With both module-level versions and GODEBUG, the whole thing does seem quite a bit more complicated than editions.
> The setting is opt-out, requiring manual intervention.
No. If a module's go.mod files declares go1.21, the compiler will use go1.21 semantics when building it, even if 1.22 has already been published and the module is being used from a 1.22-enabled program. This is explicitly mentioned in the blog post.
It's basically a much more featured, flexible, extendable, and usable version of editions. Anything you could do with editions you could do with this; you could implemented "editions" via this functionality.
> The compiler will always support old code written against older editions, but the language can still introduce breaking changes in newer editions. Developers can either opt in to new editions and migrate their code, or do nothing, and things continue to work fine. There is seamless/transparent interoperability.
This is exactly what the GODEBUG scheme described in the article is intended to allow.