FYI, json/v2 just dropped: https://go.dev/doc/go1.27#jsonv2 and log/slog has been a thing since 1.21: https://go.dev/doc/go1.21#slog

> a lot of the Go standard library is also extremely low quality

Now adjust your definition of "a lot" to include all other languages instead of apparently arbitrarily deciding that "a lot" means at best 10 and pretending that "weird edge cases all over the place" isn't normal.

I also wonder what your issue is with most of those, especially since e.g. regexp is excellent in the context of this thread - it runs in linear time, so it's not possible to craft a malicious input that will make it slow down to a crawl.

> Over time many will probably get new incompatible versions just like json.

What a bizarre statement to make.

FYI: "The encoding/json package is now backed by the v2 implementation.". You get all the benefits possible from the v2 implementation for free while maintating backwards compat and if you want to upgrade to something better, v2 is right there.

Do you have some magical suggestion how this could have possibly been handled better? And no, not having json in the stdlib isn't a viable path, that's just a cop out. But I guess since e.g. Rust and Java don't have json in their stdlibs at all, you can't say their json packages are bad, how clever and smart!

Another frequently made suggestion straight from la-la land is just writing perfect code from the get-go. Brilliant, can't believe nobody's ever thought of that.

Meanwhile in the real world, you've been able to reap the benefits of the solid encoding/json for over a decade now, and with v2 you get some nice free backwards compatible improvements and have a clear path to upgrading to v2. Perfectly handled IMO.

> Another frequently made suggestion straight from la-la land is just writing perfect code from the get-go.

The code in those packages is so far from perfect it's absurd. Like most Go developers, you just have extremely low standards.