Sonnet: High performance JSON decoder in Go(github.com)
github.com
Sonnet: High performance JSON decoder in Go
https://github.com/sugawarayuuta/sonnet
24 comments
It's been forked a bunch of times in the past.
Which also show only a few commits, initial commit being dump of the project like this one.
Anyway, I'm not a fan of this style of using Git, but personal projects are ultimately, personal, to each their own.
Anyway, I'm not a fan of this style of using Git, but personal projects are ultimately, personal, to each their own.
Sure, live and let live, but there is no way I would use a library that doesn't maintain a version history, especially so given the nature of go's non-centralized dependency management system.
Even if you pin your dependencies to a particular commit hash, eventually github will garbage collect detached commits, and your project will fail to build.
Even if you pin your dependencies to a particular commit hash, eventually github will garbage collect detached commits, and your project will fail to build.
The Go module proxy would likely keep it around, but I wouldn't feel great about relying on a "proxy only" dependency.
https://github.com/sugawarayuuta/benchmark - Performance looks pretty comparable to go-json (https://github.com/goccy/go-json). Faster in some tests, slower in others. Not sure if it'd be worth switching for me. Good work either way. Would be interested to see benchmarks of the latest version.
Whenever I see one of those supposedly better implementation of something, I always wonder why don't their author simply PR the standard library with their superior implementation? Go is quite pragmatic in its approach to things, I have never seen any interaction with core maintainer that went bad if someone had a better solution in every possible way
If I had to guess, “hey you should adopt my library, it isn’t in production use anywhere but look at these benchmarks” is a harder sell than “lots of people are already using this and it works really well, all significant bugs raised have been fixed, and hey look at these benchmarks while you’re at it”.
[deleted]
How does this compare to the ones from segment?
Why not read the github ReadMe. It has benchmarks section
Sorry, I missed the link to https://github.com/sugawarayuuta/benchmark – I don't find its contents very easy to digest, and there's often more to an encoding library than benchmark perf - how does it compare in terms of functionality, correctness, etc would be great to cover too. The README just has vague discussion of "some other alternatives" which isn't very actionable.
Those don’t make much sense to me nor do I see a comparison with the segment high performance json library.
> Those don’t make much sense to me nor do I see a comparison with the segment high performance json library.
There is a column named SegmentJSON in the benchmarks page [1]
[1] https://github.com/sugawarayuuta/benchmark
There is a column named SegmentJSON in the benchmarks page [1]
[1] https://github.com/sugawarayuuta/benchmark
Thanks
> 1 commit
cmon man, dont do that.
for the lay people, this person rebased to remove the ENTIRE history of the project.
cmon man, dont do that.
for the lay people, this person rebased to remove the ENTIRE history of the project.
[deleted]
What exactly does that hide? I don't any good motivation to drop the whole history. And it does not help trust.
Most of the time the reason isn't nefarious, but rather that people aren't interested in (a) doing the versioning work as they implement things bit by bit and (b) exposing their "draft" copy work while they are still trying out things that fail.
How fast and safe was it before? Seems to be no way of knowing, as the git history has been blown away, what's up with that?