The fact that this took 6 years to land stood out to me.
I'm not entirely surprised, and I'm glad the Go team is carefully considering their interfaces before launching. But 6 years seems like a lot of work to land a JSON API.
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.
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.
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)
I’ve written package management tools and I agree that dependency management is hard. Though I wouldn’t say it’s that hard compared to the other problems you encounter with language development.
But difficulty aside, 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.
Interesting, I came to the opposite conclusions, but for the same reasons. I like that they waited to see what alternative proposals/implementations were out there before they decided on their own.
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.
> 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.
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.
And not all on the team were convinced even after Featherweight Go, 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
> instead of hand-waving it away as needless fluff.
If you go back and watch the original Go announcement it was made abundantly clear that they believed Go did need generics 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 a better use of their time. There are so many hours in the day.
Gonuts is full of content that they were not keen in generics, in fact gccgo has been abandoned, and I expect it to eventually follow gcj and be removed from GCC.
Go culture is not welcoming to experts contributions, Rust, D, C#, Swift and others, heck even Java, are more open arms to language designers.
Nobody is keen about language features. Each new one adds complexity. That isn't the same as failing to recognize a need, though. And we know the Go team recognized the need as they clearly kept working on generics all the way from the very beginnings up until the Haskell muscle showed up. The receipts are there. The results just weren't good, as one would expect from a team who weren't shy to say that they didn't have the expertise necessary.
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" needing to get out.
Some did try, and were welcomed with stones, clubs and pitchforks, until leadership had to reach out for help, from the same team that designed Java generics, years before Go v1.0 came to materialise.
The Haskell muscle had proven their skills already with Featherweight Java, in 2006.
The same people who were working on generics in Go prior to v1 were also still there to help out when it eventually landed, so whatever stones, clubs, and pitchforks you saw weren't compelling enough to scare one away from making it happen. Not that anyone would expect them to. Meaningless distractions don't get in the way when doing something is worthwhile.
But obviously "go doesn't have generics lol" comments on HN were even more important. Just think of what would have happened if that wasn't repeated multiple times daily for years and that effort was put into getting Go generics into place much sooner. Count your lucky stars or something.
And there was plenty of effort given by others who also weren't experts. There was no lack of trying within a sea of incapable people. Unfortunately, that wasn't what the project needed. It already had a team full of blub developers, it being a language for them.
Look at the incentives. Google makes money from scam ads. Most ads I see online are scams of some sort. If Google completely blocked scams, they might not be in business.
Yes I understand that Google says they care a lot about scams and that there are people there working on blocking scams. But those are words. We need to look at money.
There is a very simple way that Google can block basically all scam ads: review all ads manually before approval, and allow no dynamic changes. They won’t do this, because it would implode their business model.
Look at the incentives. Google makes money from ads. Bad ads cause users to distrust Google ads, causing those users to be less valuable, causing advertisers to spend less with Google.
The goal is maintaining a continuous stream of revenue, not killing the stream for short term gains.
Advertisers don’t care about what other ads are doing, why would they?
Google not only benefits from scam ads, they innovated the entire scam ad economy. Prior to the proliferation of automated online ad services, ads on TV, print media et al were carefully reviewed. There were very little scams.
Naturally such a business has a scaling cap. Online websites would collaborate with advertisers directly, and there were little to no scams. Then Google and others entered the picture and innovated automatic ads with virtually no human verification. After that, we saw an entire online scam ad economy explode.
It’s not just that Google doesn’t care enough about scam ads. They created scam ads, it’s their bread and butter. Not just Google either, we see the same thing with meta on their platforms. The scams will not go away.
Very much seems to me like they realized probably a decade ago they anyone smart enough to distrust ads uses a blocker and that the vast overwhelming majority of people are just completely unaware of any risk an ad could pose.
It genuinely seems like the "ad integrity" department is a fig leaf to keep regulators away from the billion dollar scam ad business, and the people in said department believing otherwise doesn't convince me in the slightest. Soldiers in Afghanistan really thought they were liberators, but that doesn't mean that's actually why they were there
People keep making these comparisons like they're equivalent. The whole point of AI is to replace the human factor. Horses being replaced by automobiles didn't remove the human factor. Humans continued to drive a different, non-organic vehicle for the following century.
In this case it's an excellent comparison. Many in transportation just liked the transportation aspect, and the switch from horse to automobile didn't matter. Some people were just there for the horses, and to them it did matter.
Do you have a link about the 36 million developers who joined Github in 2025? I think a lot of these "developers" are AI agents / bots, but I would like to know better. Thanks!
> "Every second, more than one new developer on average joined GitHub—over 36 million in the past year. It’s our fastest absolute growth rate yet and 180 million-plus developers now work and build on GitHub."
> "Developers created more than 230 new repositories every minute, merged 43.2 million pull requests on average each month (+23% YoY), and pushed nearly 1 billion commits in 2025 (+25.1% YoY)—including a record of nearly 100 million in August alone."
No, AI is meant to replaces the manual coding work. Without the human factor, you have a data center doing nothing. You still have to tell AI what to build. You still have to deal with reality affecting your business, with market changes and new features and translating asks into a product that serves multiple types of users.
Maybe we get rid of engineers and have really good product managers. Maybe we get rid of product managers and have really good product engineers. But we don't get rid of humans. There is a reason no (successful) company ever said "we finished the app, now fire all the engineers and collect money forever."
Software is never finished, only abandoned as the world passes it by.
Less and less humans will be needed to support these businesses.
> There is a reason no (successful) company ever said "we finished the app, now fire all the engineers and collect money forever."
1) software is very easy to get duplicated and commoditized. So the margins get tighter and tighter and companies with "finished software" will have less and less money to be collected. Big companies need constant reinvention not because customers need improvements, but to keep their lines going up in the chart.
Remember Skype before being bought by Microsoft? It was as close as I can imagine from being "finished". It could be run forever with a skeleton crew and they could be collecting a few millions of dollars forever for their service. Do you think that MS paid 7 BILLION USD because of the "finished" software?
> software is very easy to get duplicated and commoditized.
Software engineers are not required to copy files around. They are hired to figure out what is the best way to deliver the features envisioned by product managers, and how to keep things working.
> So the margins get tighter and tighter and companies with "finished software" will have less and less money to be collected.
There is no such thing as finished software. At best you decide to stop maintaining it.
I’d say a business requiring ever fewer humans would, due to competition and similar dynamics, become a kind of commodity business producing ever reducing margins.
> Software is never finished, only abandoned as the world passes it by.
I've worked at a FANG where I had the opportunity to personally witness a few teams being summarily fired after they delivered the project.
In one case they had their team manager motivate them with pep talks that if they did a fantastic job delivering the project then higher ups could be swayed to preserve their roles. So they delivered ahead of schedule, only to be fired ahead of schedule too.
The horse population in the US has dropped by more than 70% in the last 100 years (21M to 6.6M). In the same timeframe, the human population has increased 320% (105M to 320M), so the drop in "relative horses" is from 0.20 horse per human to 0.02 horse per human, or 90%.
How cool are you with the odds of your entire family surviving the next 100 years standing at about 10%?
Same.. and now everything can be done SO FAST it's just stupid.
I used to love taking the time to whiteboard my project, write the code in peace (with maybe a background show). Go through the steps of structuring, debugging, testing.
Now I can write a prompt to basically do what I do instantly, and now I'm the manager and tester of something I didn't truly even make.
So sure the upside is I can do more, and I basically have to use it because I can't even keep up with what people want me to do without it. And it also seems so silly to go back.
We were lucky for decades to get paid to do what we enjoy. Virtually no other field gets this. Maybe artists but note that very few artists make even a living from their work. So yes it sucks but as they say, "don't cry because it's over, smile because it happened".
Indeed. Regexes are _regular_, which is non hierarchical by definition.
The two are useful for different layers of abstraction: regex is for lexing and PEG is for parsing.
Speaking of the Chomsky hierarchy, last I checked, it is still unproven whether or not PEGs can parse all context free languages. Intuitively, they're _probably_ weaker than CFGs, but no one has yet provided a counter example.
PEGs aren't contained within the context-free languages, so it's not really intuitive that they're weaker, particularly as nobody has yet come up with a context-free language that a PEG cannot parse. They're capable of parsing things context-free grammars cannot.
I'm not entirely surprised, and I'm glad the Go team is carefully considering their interfaces before launching. But 6 years seems like a lot of work to land a JSON API.
reply