Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A new experimental Go API for JSON

go.dev

Post reply on HN
Print view View original

71–80 of 110 posts

Re: A new experimental Go API for JSON

#71

Post by donatj »

I'm coming in a little hot and contrarian. I've been working with the Go JSON library for well over a decade at this point, since before Go 1.0, and I think v1 is basically fine.

I have two complaints. Its decoder is a little slow, PHP's decoder blows it out of the water. I also wish there was an easy "catch all" map you could add to a struct for items you didn't define but were passed.

None of the other things it "solves" have ever been a problem for me - and the "solution" here is a drastically more complicated API.

I frankly feel like doing a v2 is silly. Most of the things people want could be resolved with struct tags varying the behavior of the existing system while maintaining backwards compatibility.

My thoughts are basically as follows

The struct/slice merge issue? I don't think you should be decoding into a dirty struct or slice to begin with. Just declare it unsupported, undefined behavior and move on.

Durations as strings? Why? That's just gross.

Case sensitivity by default? Meh. Just add a case sensitivity struct tag. Easy to fix in v1

Partial decoding? This seems so niche it should just be a third party libraries job.

Basically everything could've been done in a backwards compatible way. I feel like Rob Pike would not be a fan of this at all, and it feels very un-Go.

It goes against Go's whole worse is better angle.

Re: A new experimental Go API for JSON

#72

Post by int_19h »

godisdad wrote: post #33
gethly wrote: post #6

Earlier quoted context omitted.

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

I don't recall either CORBA or SOAP ever seeing enough penetration to look "eternal" as mainstream tech goes (obviously, and especially with SOAP, there's still plenty of enterprise use). Unlike XML and JSON.

Re: A new experimental Go API for JSON

#73

Post by gethly »

ForHackernews wrote: post #48
gethly wrote: post #6

Earlier quoted context omitted.

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…

The fact that JSON is used so commonly for web stuff seems like an argument against wasting your time optimizing it. Network round trip is almost always going to dominate. If you're pushing data around on disk where the serialization library is your bottleneck, pick a better format.

There is no better human-readable format. I looked. The only alternative i considered was Amazon Ion but it proved to bring no additional value compared to json.

Re: A new experimental Go API for JSON

#74

Post by int_19h »

rplnt wrote: post #35
tibbe wrote: post #28

> 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, shou…

It is different from nil, but then again a nil map in Go behaves like an empty map when reading from it. If you consider serialization to be "reading", therefore, it makes sense to interpret it accordingly.

Re: A new experimental Go API for JSON

#75

Post by int_19h »

afdbcreid wrote: post #36

This 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.

It's not like this is new. Look at Java and .NET collection APIs, for example - both languages have the OG 1.0 versions, and then the more modern ones. In a similar vein, .NET has four different ways to deal with XML, of which three (XmlDocument, XPathDocument, and XDocument) are basically redundant representations of XML trees, each one doing things differently based on lessons learned.

It's still better than the mess that is Node.js.

Re: A new experimental Go API for JSON

#76

Post by materielle »

binary132 wrote: post #32
tibbe wrote: post #28

> 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 {}.

It should be marshaled into {} by default, with a opt-out for special use cases.

There’s a simple reason: most JavaScript parsers reject null. At least in the slice case.

Re: A new experimental Go API for JSON

#77

Post by pjmlp »

ronsor wrote: post #11
tptacek wrote: post #10

Earlier quoted context omitted.

What does "highly optimized" have to do with whether it's in the standard library? Highly-optimized cryptography is in the standard library.

Not to mention that Go is never going to put C code in the standard library for anything portable. It's all Go or assembly now.

Which is the right approach, and one of the areas I actually appreciate the work of Go authors.

There is nothing special about C, other that its historical availability after UNIX's free beer came to be.

Any combination of high level + Assembly is enough.

Re: A new experimental Go API for JSON

#78

Post by romantomjak »

phoenixhaber wrote: post #54

I will say this and I feel it's true. Dealing with JSON in Go is a pain. You should be able to write json and not have to care about the marshalling and the unmarshalling. It's the way that serde rust behaves and more or less every other language I've had to deal with and it makes managing this behavior when there's multiple writers complicated.

Are you referring to the json macro that allows variable interpolation? Doing that will void type safety. Might be useful in dynamic languages like Python but I wouldn’t want to trade type safety for some syntactic sugar in Go

Re: A new experimental Go API for JSON

#79

Post by karel-3d »

tptacek wrote: post #10
gethly wrote: post #6

Earlier quoted context omitted.

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…

What does "highly optimized" have to do with whether it's in the standard library? Highly-optimized cryptography is in the standard library.

sonic uses a clang-generated ASM, built from C (transformed from normal clang-generated ASM to "weird" go ASM via python script)... I don't think this will be in standard library.

Re: A new experimental Go API for JSON

#80

Post by drej »

Please do run this on your own workloads! It's fairly easy to set up and run. I tried it a few weeks ago against a large test suite and saw huge perf benefits, but also found a memory allocation regression. In order for this v2 to be a polished release in 1.26, it needs a bit more testing.
Post reply on HN