41–50 of 110 posts
Benchmark Analysis: Sonic vs Standard JSON vs JSON v2 in Go https://github.com/centralci/go-benchmarks/tree/b647c45272c7...
second of all, sonic apparently uses unsafe to (unsafe-ly) cast byte slices to strings, which of course is gonna be faster than doing things correctly, but is also of course incomparable to doing things correctly
like almost all benchmark data posted to hn -- unsound, ignore
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.
Earlier quoted context omitted.
> immediately JSON library released with Go 1, in 2012. This makes the library 13 years old [0]. If that's immediate , I'm fine with that kind of immediate. [0]: https://pkg.go.dev/encoding/json@go1
"immediately be in need of maintenance" means it needed this update 13 years ago.
Earlier quoted context omitted.
"immediately be in need of maintenance" means it needed this update 13 years ago.
encoding/json works perfectly great even today, please troll somewhere else
Benchmark Analysis: Sonic vs Standard JSON vs JSON v2 in Go https://github.com/centralci/go-benchmarks/tree/b647c45272c7...
Earlier quoted context omitted.
"immediately be in need of maintenance" means it needed this update 13 years ago.
encoding/json works perfectly great even today, please troll somewhere else
Obviously encoding/json doesn't "work perfectly", the TFA lists several problems it has, and the need for a new version, and that's directly by the horse's mouth. Is the Go team "trolling" as well?
Second, we're not talking whether it "does the job", which is what you might mean by "works perfectly great".
We're talking about whether it's a good design for the problem domain, or whether it has footguns, bad API choices, performance problems, and other such issues.
I still don't get how a common thing like JSON is not solved in go. How convoluted it is to just get a payload from an api call compared to all languages is baffling
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…
If you're pushing data around on disk where the serialization library is your bottleneck, pick a better format.
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?
Now here’s a new implantation that addresses some of the architectural problems that made the old library structurally problematic for some use cases (streaming large JSON docs being the main one).
I still don't get how a common thing like JSON is not solved in go. How convoluted it is to just get a payload from an api call compared to all languages is baffling