Sometimes I wonder about Go's velocity - generics (something that I still haven't used beyond the tutorials) took an age as well

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

▲

hnlmorg 4 hours ago | parent | next [-]

I think in the case of JSON, it was “good enough”. People who found this to be a problem would use one of the many 3rd party options.

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.

	▲	awesome_dude 2 hours ago \| parent [-]
		lol, I don't mean to be contrary, but I looked into dependency management (partly because of the modules implementation, partly because of early teething issues, and partly out of pure curiousity. 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)

▲

Philip-J-Fry an hour ago | parent | prev | next [-]

For like 99% of use cases encoding/json was fine. Of course improvements are welcomed. But personally I've lead development of the backend of part one of the biggest sites of its kind in the world, and we just used encoding/json and net/http. Most of our use cases are just building APIs, client facing ones, internal ones, trusted third-parties. These systems have pretty high throughput, more than most people will ever work on.

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.

▲

win311fwg 4 hours ago | parent | prev [-]

> generics (something that I still haven't used beyond the tutorials) took an age as well

Only about a year from when the Haskell guys lent their expertise in designing it 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 capabilities internally, despite a lot of failed efforts trying anyway, and were relying on the open source community to lend a hand. Unfortunately, open source doesn't mean open willingness to contribute. It turns out that for all the experts on HN, posting "go doesn't have generics lol" was preferable to helping out.

▲

enneff 4 hours ago | parent [-]

Haskell guys? Got a reference to this? That’s news to me.

▲

0x696C6961 3 hours ago | parent [-]

I'm not sure about the haskell association, but search for "Featherweight Go"

	▲	enneff 3 hours ago \| parent [-]
		Thanks for the pointer. The reference makes sense now, as Philip Wadler is a coauthor of that paper.