How does this compare to the ones from segment?

Why not read the github ReadMe. It has benchmarks section

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

Thanks

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.

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

> is now even faster and safer

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?

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.

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.

The Go module proxy would likely keep it around, but I wouldn't feel great about relying on a "proxy only" dependency.

> 1 commit

cmon man, dont do that.

for the lay people, this person rebased to remove the ENTIRE history of the project.

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.

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.

How is it compared to bytedance/sonic?

Sorry, I was only comparing go-json because both Sonnet and go-json are drop-in replacements for the standard library's JSON encoder and decoder.

Hey, what is this? Project with exactly one commit from a user with no other projects, no recent contributions.

Is this a real library or some honeypot?

Seems very suspicious and dangerous. I would not touch it or install it.

They brought the history back. Now it's 6 commits.