A bad design doesn't invalidate the sentence you have quoted.

Over time, it became evident that the JSON package didn't meet the needs of its users, and the package has evolved as a result. The size of the evolution doesn't matter.

▲

coldtea 3 days ago | parent | next [-]

"Becoming evident it doesn't meet the needs of its users" is not the same as "packages evolve with the needs of their users".

The latter is a weasely way to put the blame on changing needs - as if initially it was fine, but user needs grew and it's not covering them anymore. Truth is, user needs are the same, we havent had any magical change in JSON use patterns over the last 10 years. The design was just flawed to begin with.

I'd argue it didn't "become evident over time" either. It was evident on day one, and many people pointed it out 10 and 13 years ago.

▲

pcthrowaway 3 days ago | parent | prev [-]

It's true that packages (generally) evolve with the needs of their users.

It's also true that a json IO built-in lib typically wouldn't be so poorly designed in the first release of a language, that it would immediately be in need of maintenance.

▲

bayindirh 3 days ago | parent [-]

> immediately

JSON library released with Go 1, in 2012. This makes the library 13 years old [0].

If that's immediate, I'm fine with that kind of immediate.

[0]: https://pkg.go.dev/encoding/json@go1

▲

coldtea 3 days ago | parent | next [-]

"immediately be in need of maintenance" means it needed this update 13 years ago.

▲

kiitos 3 days ago | parent [-]

encoding/json works perfectly great even today, please troll somewhere else

	▲	coldtea 3 days ago \| parent \| next [-]
		Please don't use the "troll" accusation to something because you disagree with it. It's weasely. Obviously encoding/json doesn't "work perfectly", the TFA lists several problems it has, and the need for a new version, and that's directly by the horse's mouth. Is the Go team "trolling" as well? Second, we're not talking whether it "does the job", which is what you might mean by "works perfectly great". We're talking about whether it's a good design for the problem domain, or whether it has footguns, bad API choices, performance problems, and other such issues.
	▲	pcthrowaway 3 days ago \| parent \| prev [-]
		It works well enough, despite being clunky, but it has a few issues, including significant performance-related ones.

▲

pcthrowaway 3 days ago | parent | prev [-]

In need of maintenance and having received maintenance are two different things