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

101–110 of 110 posts

Re: A new experimental Go API for JSON

#101

Post by tubthumper8 »

materielle wrote: post #76
binary132 wrote: post #32

Earlier quoted context omitted.

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.

Not sure what you mean here by "most JavaScript parser rejects null" - did you mean "JSON parsers"? And why would they reject null, which is a valid JSON value?

It's more that when building an API that adheres to a specification, whether formal or informal, if the field is supposed to be a JSON array then it should be a JSON array. Not _sometimes_ a JSON array and _sometimes_ null, but always an array. That way clients consuming the JSON output can write code consuming that array without needing to be overly defensive

Re: A new experimental Go API for JSON

#102

Post by ForHackernews »

kbolino wrote: post #93
ForHackernews wrote: post #48

Earlier quoted context omitted.

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

If you're optimizing for energy wasted serving your website you could stop sending 10 megs of garbage javascript on page load.

Re: A new experimental Go API for JSON

#103

Post by leononame »

int_19h wrote: post #74
rplnt wrote: post #35

Earlier quoted context omitted.

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.

That is not true, though. Reading from a nil map panics, and reading from an empty map does not.

Re: A new experimental Go API for JSON

#104

Post by kbolino »

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…

Without any major changes, struct tags cannot solve the majority of the problems, because they do not propagate. The v1 MarshalJSON/UnmarshalJSON interfaces are too simplistic. At the very least, an alternative pair of interfaces should exist, which take options/flags/tags/whatever in the parameters. However, I agree this doesn't need to be in an entirely new package. It's not even hard to favor one interface over another:

  switch ifc := val.(type) {
    case MarshalJSONV2: // new interface, always used if present
    case MarshalJSON:   // old interface, fallback
    default:            // type isn't self-marshaling
  }
The jsontext package is what's really revolutionary and needed here. The poor performance of the existing API is due primarily to the lack of a proper streaming API as the foundation. Using this as the basis for the new interfaces makes sense, and I agree that once this exists, the need for an entirely separate v2 package largely vanishes.

Re: A new experimental Go API for JSON

#105

Post by int_19h »

leononame wrote: post #103
int_19h wrote: post #74

Earlier quoted context omitted.

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.

That is not true, though. Reading from a nil map panics, and reading from an empty map does not.

It doesn't. E.g. this prints 0:

var m map[string]int = nil fmt.Println(m["foo"])

The language spec is also pretty clear on this; https://go.dev/ref/spec#Map_types:

> A nil map is equivalent to an empty map except that no elements may be added.

Re: A new experimental Go API for JSON

#106

Post by int_19h »

pjmlp wrote: post #81
int_19h wrote: post #72

Earlier quoted context omitted.

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.

They surely were, for anyone doing enterprise during the 2000's. We had no plans to change to something else.

I recall a lot of talk about CORBA in early 00s, but I don't think I've actually ever seen it used anywhere outside of Gnome.

By late 00s, even the talk was more along the lines of it being legacy tech.

Re: A new experimental Go API for JSON

#107

Post by kristianp »

nasretdinov wrote: post #16
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…

Go doesn't yet have native SIMD support, but it actually might in the future: https://github.com/golang/go/issues/73787 I think when it's introduced it might be worth discussing that again. Otherwise providing assembly for JSON of all packages seems like a huge maintenance burden for very little benefit for end users (since faster alternatives are readily available)

Interesting that the proposal is for low-level intrinsics as well as a non-processor-specific api: > Our plan is to take a two-level approach: Low-level architecture-specific API and intrinsics, and a high-level portable vector API. The low-level intrinsics will closely resemble the machine instructions (most intrinsics will compile to a single instruction), and will serve as building blocks for the high-level API.

Re: A new experimental Go API for JSON

#108

Post by pjmlp »

int_19h wrote: post #106
pjmlp wrote: post #81

Earlier quoted context omitted.

They surely were, for anyone doing enterprise during the 2000's. We had no plans to change to something else.

I recall a lot of talk about CORBA in early 00s, but I don't think I've actually ever seen it used anywhere outside of Gnome. By late 00s, even the talk was more along the lines of it being legacy tech.

Several Nokia Networks products were based on CORBA, running on HP-UX, in a mix of C++ and Perl.

Eventually migrated to Java EE, also taking advantage of CORBA compatibility.

Re: A new experimental Go API for JSON

#109

Post by SSLy »

pjmlp wrote: post #108
int_19h wrote: post #106

Earlier quoted context omitted.

I recall a lot of talk about CORBA in early 00s, but I don't think I've actually ever seen it used anywhere outside of Gnome. By late 00s, even the talk was more along the lines of it being legacy tech.

Several Nokia Networks products were based on CORBA, running on HP-UX, in a mix of C++ and Perl. Eventually migrated to Java EE, also taking advantage of CORBA compatibility.

Q3 is still in C++. Huawei also still supports CORBA.

Re: A new experimental Go API for JSON

#110

Post by dematz »

dematz wrote: post #87
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…

I like the "does the problem justify the solution's complexity" question. The deserialization performance improvement seems like an actually important benefit though. Also https://antonz.org/go-json-v2/#marshalwrite-and-unmarshalrea... not completely sure but maybe combining dec := json.NewDecoder(in) dec.Decode(&bob) to just json.UnmarshalRead(in, &bob) is nicer...mostly the performance benefit though

Although actually, for streaming maybe it would still be 2 lines but from jsontext..

dec := jsontext.NewDecoder(in)

json.UnmarshalDecode(in, &bob)

Post reply on HN