I still don't get how a common thing like JSON is not solved in go.
How convoluted it is to just get a payload from an api call compared to all languages is baffling
A new experimental Go API for JSON
31–40 of 110 posts
Re: A new experimental Go API for JSON
#32> Since encoding/json marshals a nil slice or map as a JSON null How did that make it into the v1 design?
how is a nil map not null? It certainly isn’t a zero-valued map, that would be {}.
Re: A new experimental Go API for JSON
#33Benchmark Analysis: Sonic vs Standard JSON vs JSON v2 in Go https://github.com/centralci/go-benchmarks/tree/b647c45272c7...
Those numbers look similar to goccy. I used to use it in the past, even Kubernetes uses it as direct dependency, but the amount of issues have been stockpiling for quite some time so I no longer trust it. So it seems both are operating at the edge of Go's capabilities. Personally, I think JSON should be in Go's core and highly optimised simd c code and not in the Go's std library as standard Go code. As JSON is such…
> As JSON is such an important part of the web nowadays, it deserves to be treated with more care.
There is a case to be made here but Corba, SOAP and XML-RPC likely looked similarly sticky and eternal in the past
Re: A new experimental Go API for JSON
#34If/once this goes through, I wonder what the adoption is going to be like now that all LLMs still only have the v1 api in their corpus.
Re: A new experimental Go API for JSON
#35> Since encoding/json marshals a nil slice or map as a JSON null How did that make it into the v1 design?
Well those are different things, aren't they? Empty slice/map is different from nil. So it makes a lot of sense that nil = null and []string{} = [], and you have an option to use both. That being said, it starts to make less sense if you work with go where the API mostly treats it as equivalent (append, len, []). So that would be my guess how it ended up the way it did.
Also, now that nil map is an empty object, shouldn't that extend to every nil struct that doesn't have a custom marshaller? It would be an object if it wasn't nil after all...
Re: A new experimental Go API for JSON
#36This is the second time a v2 is released to a package in the Go's standard library. Other ecosystems are not free of this problem.
And then people complain that Rust doesn't have a batteries-included stdlib. It is done to avoid cases like this.
Re: A new experimental Go API for JSON
#37> Since encoding/json marshals a nil slice or map as a JSON null How did that make it into the v1 design?
Why shouldn't it be? The nil is null and empty array is an empty array, they are completely different objects.
Re: A new experimental Go API for JSON
#38Could somebody give a high level overview of this for me, as not a godev? It looks like Go JSON lib has support to encode native go structures in JSON, which is cool, but maybe it was bad, which is not as cool. Do I have that right?
Go already has a JSON parser and serializer. It kind of resembles the JS api where you push some objects into JSON.stringify and it serializes them. Or you push some string and get an object (or string etc) from JSON.parse. The types themselves have a way to customize their own JSON conversion code. You could have a struct serialize itself to a string, an array, do weird gymnastics, whatever. The JSON module calls th…
gjson/sjson is probably for you if you need to work with 100MB JSONs.
Re: A new experimental Go API for JSON
#39This is the second time a v2 is released to a package in the Go's standard library. Other ecosystems are not free of this problem. And then people complain that Rust doesn't have a batteries-included stdlib. It is done to avoid cases like this.
Wow, two whole times in 19 years? That sounds terrible.
Yes, we should definitely go with the Rust approach instead.
Anyway, I'd better get back to figuring out which crate am I meant to be using...
Re: A new experimental Go API for JSON
#40This is the second time a v2 is released to a package in the Go's standard library. Other ecosystems are not free of this problem. And then people complain that Rust doesn't have a batteries-included stdlib. It is done to avoid cases like this.
That has its own downsides, though.
Both v1 packages continue work; both are maintained. They get security updates, and were both improved by implementing them on top of v2 to the extent possible without breaking their respective APIs.
More importantly: the Go authors remain responsible for both the v1 and v2 packages.
What most people want to avoid with a "batteries included standard library" (and few additional dependencies) is the debacle we had just today with NPM.
Well maintained packages, from a handful of reputable sources, with predictable release schedules, a responsive security team and well specified security process.
You can't get that with 100s of independently developed dependencies.