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

91–100 of 110 posts

Re: A new experimental Go API for JSON

#91

Post by kbolino »

physicles wrote: post #68

Love seeing meaningful stdlib improvements. I just ran our full suite of a few thousand unit tests with GOEXPERIMENT=jsonv2 and they all passed. (well, one test failed because an error message was changed, but that's on us) I'm especially a fan of breaking out the syntactic part into into its own jsontext package. It makes a ton of sense, and I could see us implementing a couple parsers on top of that to get better p…

I think the "omitempty" tag name might be too tarnished to keep around, but I think the distinction made between its redefined meaning and the new "omitzero" tag in v2 is quite useful:

- "omitempty" will omit an object field after encoding it, according to its JSON value

- "omitzero" will omit an object field before encoding it, according to its Go value

The former is particularly useful when you are dealing with foreign types that don't implement IsZero (yet) or implement it in an inappropriate way for how you're using it. You could, of course, write a wrapper type, but even when you can use struct embedding to make the wrapper less painful, you still have to duplicate all of the constructors/factories for that type, and you have to write the tedious code to do the conversions somewhere.

Re: A new experimental Go API for JSON

#93

Post by kbolino »

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.

This is an interesting perversion of Amdahl's law.

Yes, if you are looking at a single request-response interaction over the Internet in isolation and observing against wall clock time, the time spent on JSON (de-)serialization (unless egregiously atrocious) will usually be insignificant.

But that's just one perspective. If we look at CPU time instead of wall clock time, the JSON may dominate over the network calls. Moreover, in a language like Go, which can easily handle tens to hundreds of thousands of parked green threads waiting for network activity, the time spent on JSON can actually be a significant factor in request throughput. Even "just" doubling RPS from 10k to 20k would mean using half as much energy (or half as much cloud compute spend etc.) per request.

Changing formats (esp to a low-overhead binary one) might yield better performance still, but it will also have costs, both in time spent making the change (which could take months) and adapting to it (new tools, new log formats, new training, etc.).

Re: A new experimental Go API for JSON

#94

Post by saghm »

donatj wrote: post #71

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 "s…

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

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

One could almost say that durations as strings is...worse.

Re: A new experimental Go API for JSON

#95

Post by rowanseymour »

maleldil wrote: post #84
stackedinserter wrote: post #37

Earlier quoted context omitted.

Why shouldn't it be? The nil is null and empty array is an empty array, they are completely different objects.

Not in Go. Empty slices and empty maps are nil, so it's ambiguous.

To be precise.. empty slices and maps sometimes behave like nil (len, range etc) and sometimes not (inserting into a nil map). The former is a neat convenience, and I think extending that to JSON marshaling makes sense.

Re: A new experimental Go API for JSON

#96

Post by kanbara »

gethly wrote: post #4

This V2 is still pushing forward the retarded behavior from v1 when it comes to handling nil for maps, slices and pointers. I am so sick and tired of this crap. I had to fork the v1 to make it behave properly and they still manage to fuck up completely new version just as well(by pushing omitempty and ignoring omitnil behavior as a standalone case) which means I will be stuck with the snale-pace slow v1 for ever.

you know you can make your case better if you don’t use disrespectful and offensive language

Re: A new experimental Go API for JSON

#97

Post by everybodyknows »

maleldil wrote: post #89
stackedinserter wrote: post #88

Earlier quoted context omitted.

No, empty slices and empty maps in Go are not nil.

This is the idiomatic way of declaring empty slices in Go, and it prints true: var slice []string fmt.Println(slice == nil)

Whether to judge the line below idiomatic, or not, is a question I leave to the authorities -- but it is highly convenient, and prints "false".

  slice := []string{}
  fmt.Println(slice == nil)

Re: A new experimental Go API for JSON

#99

Post by stackedinserter »

maleldil wrote: post #89
stackedinserter wrote: post #88

Earlier quoted context omitted.

No, empty slices and empty maps in Go are not nil.

This is the idiomatic way of declaring empty slices in Go, and it prints true: var slice []string fmt.Println(slice == nil)

Yes because it's nil. You declared it but not created. Same for map. Same for var something *string

Re: A new experimental Go API for JSON

#100

Post by rnmkr »

donatj wrote: post #71

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 "s…

lol
Post reply on HN