Pretty sure Go hit 1.0 in 2012 and Swift in 2014. In any case, I think the age is not a significant indicator or driver of stability (at least for these young languages), but rather the community's commitment toward stability. The Swift community definitely seems to value stability less than the Go community.
Swift can get away with it because the majority of its users are using Xcode which has excellent tools for migrating between versions of Swift, and also interop with Objective-C code. Plus, the current compiler can target a limited number of older versions’ syntax but allowing use of new APIs for some degree of forwards compatibility in large code bases.
Whereas I doubt there’s one canonical Go dev environment common to the majority of its users to make easy migrating large code bases and providing simple syntax adjustments.
There’s a tool called fix, it’s already part of the standard Go distribution. In the past (mostly pre 1.0, IIRC?), it’s used to apply changes to one’s codebase when migrating between Go releases that introduce incompatible changes.
Can it be used in editors, say VS Code, to provide fix-its or suggestions for improving code on a line-by-line basis? If so, that sounds great. A lot of languages are missing this in their standard distributions and devs must rely on third-party offerings.
The standard go cli toolchain comes with `go fix which was used to do the update code for breaking changes or styles during the time before 1.0 release. If anything, I suspect the swift team was partially inspired by this pattern.
I doubt it. Apple's refactoring tools in Xcode go way back, thanks to the introduction of Carbon; the Intel transition; synthesised properties and automatic reference counting in Objective-C 2; and the extremely regular, breaking changes in UIKit.