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

11–20 of 110 posts

Re: A new experimental Go API for JSON

#11

Post by ronsor »

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.

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.

Re: A new experimental Go API for JSON

#12

Post by rjrodger »

null != nil !!!

It is good to see some partial solutions to this issue. It plagues most languages and introduces a nice little ambiguity that is just trouble waiting to happen.

Ironically, JavaScript with its hilarious `null` and `undefined` does not have this problem.

Most JSON parsers and emitters in most languages should use a special value for "JSON null".

Re: A new experimental Go API for JSON

#13

Post by [deleted] »

gethly wrote: post #8
ycombinatrix wrote: post #5

Earlier quoted context omitted.

What is your preferred behavior for a nil map/slice? Feels weird that it doesn't map to null.

When you are unmarshaling json, empty map/slice is something completely different than a null or no value present, as you are losing intent of the sender, in case of JSON REST. For example, if my intent is to keep the present value, I will send {"foo": 1} or {"foo": 1, "bar": null} as null and no value has the same meaning. On the other hand, I might want to change the existing value to empty one and send {"foo": 1,…

[deleted]

Re: A new experimental Go API for JSON

#14

Post by pjmlp »

rjrodger wrote: post #12

null != nil !!! It is good to see some partial solutions to this issue. It plagues most languages and introduces a nice little ambiguity that is just trouble waiting to happen. Ironically, JavaScript with its hilarious `null` and `undefined` does not have this problem. Most JSON parsers and emitters in most languages should use a special value for "JSON null".

Fixed in 1976 by ML, followed up by Eiffel in 2005, but unfortunately yet to be made common.

Re: A new experimental Go API for JSON

#15

Post by coldtea »

>Over time, packages evolve with the needs of their users, and encoding/json is no exception

No, it's an exception. It was badly designed from the start - it's not just that people's json needs (which hardly changed) outgrew it.

Re: A new experimental Go API for JSON

#16

Post by nasretdinov »

gethly wrote: post #6
analytically wrote: post #2

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

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)

Re: A new experimental Go API for JSON

#17

Post by bayindirh »

coldtea wrote: post #15

> Over time, packages evolve with the needs of their users, and encoding/json is no exception No, it's an exception. It was badly designed from the start - it's not just that people's json needs (which hardly changed) outgrew it.

A bad design doesn't invalidate the sentence you have quoted.

Over time, it became evident that the JSON package didn't meet the needs of its users, and the package has evolved as a result. The size of the evolution doesn't matter.

Re: A new experimental Go API for JSON

#18

Post by dilyevsky »

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.

Previously Go team has been vocal about sacrificing performance to keep stdlib idiomatic and readable. Guess the crypto packages are the exception because they are used heavily by Google internally and json and some others (like say image/jpeg which had crap performance last time i checked) are not.

Edit: See: https://go.dev/wiki/AssemblyPolicy

Re: A new experimental Go API for JSON

#19

Post by sroerick »

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?

Re: A new experimental Go API for JSON

#20

Post by afiori »

rjrodger wrote: post #12

null != nil !!! It is good to see some partial solutions to this issue. It plagues most languages and introduces a nice little ambiguity that is just trouble waiting to happen. Ironically, JavaScript with its hilarious `null` and `undefined` does not have this problem. Most JSON parsers and emitters in most languages should use a special value for "JSON null".

Null and undefined are fine imho with a sort of empty/missing semantics (especially since you mostly just care to == them) I have bigger issues to how similar yet different it is to have an undefined key and a not-defined key, I would almost prefer if

    obj['key']=undefined

 was the same as 

    delete obj['key']
Post reply on HN