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

81–90 of 110 posts

Re: A new experimental Go API for JSON

#81

Post by pjmlp »

int_19h wrote: post #72
godisdad wrote: post #33

Earlier quoted context omitted.

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

They surely were, for anyone doing enterprise during the 2000's.

We had no plans to change to something else.

Re: A new experimental Go API for JSON

#82

Post by pjmlp »

mdaniel wrote: post #62
godisdad wrote: post #33

Earlier quoted context omitted.

> 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 hear you, but I am not aware of anyone that tried XMLHttpRequest.send(' ' friend from the browser. I think that's why they cited "of the web" and not "of RPC frameworks"

No, because that was server's job on the endpoint.

Re: A new experimental Go API for JSON

#83

Post by _w1tm »

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

Eternal or not, right now JSON is used everywhere which means the performance gains of a more optimized Stalin would be significant. Just because we don’t know if JSON is around in 10 years doesn’t mean we should settle for burning extra compute on it.

Re: A new experimental Go API for JSON

#84

Post by maleldil »

stackedinserter wrote: post #37
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?

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.

Re: A new experimental Go API for JSON

#85

Post by lsaferite »

dmoy wrote: post #56
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.

> serde rust That does look a lot cleaner. I was just grumbling about this in golang yesterday (yaml, not json, but effectively the same problem).

I work in go every day and generally enjoy it.

The lack of tagged unions of some sort in go makes things like polymorphic json difficult to handle. It's possible, but requires a ton of overhead. Rust with enums mixed with serde makes this trivial. Insanely trivial.

Re: A new experimental Go API for JSON

#86

Post by tucnak »

eknkc wrote: post #27
sroerick wrote: post #19

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

> If that JSON string is 100MB long, too bad, it has to be read completely and allocated again for you to work on because you can only accept a byte array to parse.

I was not sure whether this was the case, as `json.NewEncoder(io.Writer)` and `json.NewDecoder(io.Reader)` exist in v1, so I had checked, and guess what, you're right! Decode() actually reads the value to internal buffer before doing any marshalling in the first place. I had always assumed that it kept internal stack of some kind, for matching-parenthesis and type safety stuff within streaming context, but no, it doesn't do any of that stuff! Come think of it: it does make sense, as partial-unmarshal would be potentially devastating for incrementally-updated data structures as it would leave them to inconsistent state.

Re: A new experimental Go API for JSON

#87

Post by dematz »

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

Re: A new experimental Go API for JSON

#88

Post by stackedinserter »

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.

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

Re: A new experimental Go API for JSON

#89

Post by maleldil »

stackedinserter wrote: post #88
maleldil wrote: post #84

Earlier quoted context omitted.

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

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)

Re: A new experimental Go API for JSON

#90

Post by tux3 »

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)

This is indeed a nil slice, and it does have len() == 0, but Go also has a concept of empty slices separate from nil slices

The language just has a bad habit of confusing them some of the time, but not consistently, so you can still occasionally get bit by the difference

As someone who uses Go a lot, it's just one of those things...

Post reply on HN