Go’s alias proposal and all my concerns of Google controlling Go
To me the root problem for this alias proposal is that go currently ignores version dependencies.<p>Go is designed so that we have to assume that an API and the compiler are either perfectly backward compatible or immutable. This is a simplification inherited from C and other programming languages.<p>If we want to support changing an API, then we have to specify version along the package name and import statement. Some packages already do that but it isn't satisfying because it is hardcoded in the package name.<p>I like the versioning rule chosen by ICE from zeroc. A version is not backward compatible with other versions. A release must be backward compatible with previous release of the same version.<p>So it should be possible to specify a version and release for packages in import statements which specify that the specified release and all subsequent release are valid.<p>Dub, for the D programming language is going that line of direction.<p>I'm aware that it may create a dependency hell. But it already exist and is hidden. The alias hack is not a good solution. It will make things worse by making the rules more lax.