JSON processing, quite markedly, is renown in Go for being slow, so I don't really understand why it took so long

I kind of like that the standard library doesn’t move fast. It makes it easier to fit the ecosystem into my head (unlike, for example, the JavaScript ecosystem where I find code doesn’t survive 2 years before failing to compile).

But I do agree that slow and steady produces its own problems. Your example of generics is a good one. But think the example of Go modules is another, perhaps even better, example of how sometimes the Go team really should have accelerated their efforts on.

Dependency management is a freaking nightmare, nobody has managed to create something that is bulletproof, not cargo, npm, apt, yum, nix, homebrew, nothing.

The key issue is that you're managing 3rd party software that may or may not adhere to the prescribed lifecycle/versioning

The Linux variants do it by each having dedicated teams watching upstream sources, taking what they believe to be whatever they feel is right, building for their nominated target(s), then testing, before deploying (on top of that, all of these steps vary in importance and rigor depending on numerous variables)

For programming libraries (which is what depmod, goose, vgo, and modules are managing) it's just as bad, if not harder, because their very nature is to provide a base upon which other developers can turn into whatever their imagination.

Add to that, modules was (initially) written by people who were dealing with a slightly different ecosystem; Google rather famously has a monorepo, making their lives a little easier when it comes to managing dependencies.

So, with those things in mind, dependency management is always going to be a hard problem that is opinionated (eg. I have a firm opinion that there should be an easier way to "pin" a dependency, other than vendoring - note that this isn't an invitation to every junior Go developer to come and claim go.sum does that. It doesn't. go.sum is a log of what dependencies were used for the last build by whomever wrote to it)

But my point was Go waited until there were multiple established 3rd party package management tools for Go already in widespread use before even releasing their own experimental implementation.

Their inaction caused far more disruption to the ecosystem because people got fed up of waiting, implemented their own, integrated it into their workflow and then had to reintegrate a whole new system all over again a year or two later.

Your point about Googles needs is the one often cited for Gos inaction. But I think that actually makes the situation worse. Because if the Go team cannot empathise with use cases outside of one bespoke enterprise, then it really shouldn’t be released as a general purpose language available for all to use.

And I say this as someone who generally likes the language.

Especially since "Go team cannot empathise with use cases outside of one bespoke enterprise" — it shows self-awareness of their shorcomings. I think it's wise to let the target audience explore the design space themselves a bit first. Considerably lowers the risk of cementing the wrong design.

I do somewhat remember the drama around this at the time, but I my impression was that of a petulent community of various dependency management projects with too much ego attached to them to see the bigger, long-term picture.

Thanks for sharing.

Put this in your go.mod:

  replace example.com/package-to-pin => example.com/package-to-pin v1.2.3

Only about a year from when the Haskell guys lent their expertise and it landing in a release. That's actually fairly quick given that it was a pretty significant change under the hood and constrained by only two releases annually.

The Go team was always clear that they didn't have the necessary expertise internally and were relying on the open source community to lend a hand. Unfortunately, open source doesn't mean open willingness to contribute.

https://homepages.inf.ed.ac.uk/wadler/topics/gj.html

Before Featherweight Go, there was Featherweight Java.

So maybe a language designed in 2012 (v 1.0 release year), should learn from history instead of hand-waving it away as needless fluff.

> In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier.

https://github.com/golang/proposal/blob/master/design/go2dra...

And not all on the team were convinced, here Rob Pike,

> I think the transition to getting polymorphism into the language through generics is has still got some years to work through there's still things that don't quite work right

https://youtu.be/yE5Tpp2BSGw?t=2134

If you go back and watch the original Go announcement it was made abundantly clear that they believed Go did need generics at the time but that they didn't have the expertise to do it. Yes it is true that the book was already written on it, but that doesn't mean anyone on the Go team was familiar with it or had the time to become familiar with it. Programming languages do not require gods to design them. Imperfect humans can too.

The experts on HN who know all the ins and outs of generics could have contributed but, you know, shitposting "go doesn't have generics lol" was apparently a better use of their time. But it is certainly not for anyone else to do decide how they live their life.

Go culture is not welcoming to experts contributions, Rust, D, C#, Swift and others, heck even Java, are more open arms to language designers.

You'd think one of the HN experts would have shown up to offer that expertise, but I guess there was a lot of "go doesn't have generics lol" to get out.

The Haskell muscle had proven their skills already with Featherweight Java, in 2006.

But obviously "go doesn't have generics lol" comments were even more important. Imagine what would have happened to HN if that wasn't repeated multiple times daily for years!

Within our company I saw people in other teams writing their own optimised JSON libraries for whatever hellish reason. I always reiterated the point that as soon as that app made a single IO request all those nanosecond savings are invisible. Yes, it affects your total CPU time for processing a request but compute was never ever a limitation for us and it's likely not a limitation for most people. And if the trade off is your app needs scale slightly larger versus writing custom JSON code or pulling in a third party dependency, then I'm accepting the larger scaling.

The biggest benefit of encoding/json/v2 isn't the speed, it's the improved API.

Wordpress powered by PHP is also the most widely deployed CMS.

That argument is not as great as you think it is.

> That argument is not as great as you think it is.

But at least it is an argument in contrast to the comment I was replying to.