[stcredzero]

There’s a countervailing mindset which, in its harshest terms, says “the standard library is where code goes to die”

This can be addressed in a language with sufficient annotation and good parser tools. In some future language, there should be a unification between the version control, the de-facto codesharing site, language/library versions, and syntax-driven tools to automatically rewrite code.

It should be possible to "publish" a language and its libraries such that any breaking changes will automatically be updated when you switch library versions. (This should also be applicable to Entity-Relation diagrams and Object-Relational mappings -- those can be treated as a versioned library.)

[skybrian]

The problem is that the number of possible combinations of versions grows rapidly as you add versions. This makes testing harder, as it spreads the community thin - everyone's using a different combo than everyone else.

To avoid that, you need to standardize on a blessed set of versions to be tested together, much like assembling a release of a Linux distro.

People will still swap in alternate versions of libraries occasionally, but keeping things mostly standard and a few cherry-picks is still better than everyone choosing differently.

[stcredzero]

The problem is that the number of possible combinations of versions grows rapidly as you add versions.

The point is not to let people hang out in whatever obscure snowflake version-set they want to. The point is to make migration going forward as painless as possible. However, that expectation is not so much about the tooling as it is about the developer/language community.

To avoid that, you need to standardize on a blessed set of versions to be tested together, much like assembling a release of a Linux distro.

Yes, there should be this! However, you will still have some stragglers and outliers -- this is what the historical reality shows us. The point of such tooling is precisely to minimize the pool of stragglers, not to maximize them!

[dasmoth]

To avoid that, you need to standardize on a blessed set of versions to be tested together, much like assembling a release of a Linux distro.

That's pretty much the Stackage/LTS Haskell model. Seem to be working pretty well there.

[kbenson]

> In some future language, there should be a unification between the version control, the de-facto codesharing site, language/library versions, and syntax-driven tools to automatically rewrite code.

You actually get a lot of that in Perl 6, which identified modules not only by name, but by version and authority (so you can choose to load author Bar's version of Widget instead of author Foo's version.

[solidsnack9000]

Swift is probably the closest thing to this today, where new versions of the language ship with a migrator tool.