This is the second time a v2 is released to a package in the Go's standard library. Other ecosystems are not free of this problem.

And then people complain that Rust doesn't have a batteries-included stdlib. It is done to avoid cases like this.

That has its own downsides, though.

Both v1 packages continue work; both are maintained. They get security updates, and were both improved by implementing them on top of v2 to the extent possible without breaking their respective APIs.

More importantly: the Go authors remain responsible for both the v1 and v2 packages.

What most people want to avoid with a "batteries included standard library" (and few additional dependencies) is the debacle we had just today with NPM.

Well maintained packages, from a handful of reputable sources, with predictable release schedules, a responsive security team and well specified security process.

You can't get that with 100s of independently developed dependencies.

Wow, two whole times in 19 years? That sounds terrible.

Yes, we should definitely go with the Rust approach instead.

Anyway, I'd better get back to figuring out which crate am I meant to be using...

I’d rather have 2 jsons in the stdlib after 15 years than 0 jsons in the stdlib

Two v2s in 15 years seems pretty good given the breadth of the stdlib.

It's not like this is new. Look at Java and .NET collection APIs, for example - both languages have the OG 1.0 versions, and then the more modern ones. In a similar vein, .NET has four different ways to deal with XML, of which three (XmlDocument, XPathDocument, and XDocument) are basically redundant representations of XML trees, each one doing things differently based on lessons learned.

It's still better than the mess that is Node.js.

I'm not sure how this is a problem, and I'm very sure that even in the presence of this "problem" it is far better for a language to have a batteries-included stdlib than to not