Hi mate,

very interesting library. Keep it up.

Improvement suggestion: While reading the README, the JSON library comparison [1] it's confusing, at least to me. It uses symbols like: ○, and △ which are not obvious. I would rather use "yes/no" or the classic check/x (unicode chars, HN does not support them here) if you want to use symbols. I don't know what "△" even means, so I cannot suggest an alternative.

Just my 2 cents.

[1]: https://github.com/goccy/go-json#json-library-comparison

Edit: This 2021 I have the objective to contribute more to OS projects. Is it OKay if I submit a PR with the change? Thanks!

Another suggestion in the chart: it isn't obvious which line is about your project because it doesnt list the `goccy/` part. I would add that and move it to the top, out it and the standard in bold.

Yes, Of course !! Welcome !!

How does it handle de-serializing to structs with interface members? With encoding/json and ffjson, I had to write some code to handle that myself and add a type-tag member to my struct, which wasn't a deal-breaker, but if I could avoid that, I would like that very much.

As a Non-Gopher, is the stdlib so slow?

I think it depends on the application. In many cases, encoding/json is fast enough and stable, but I think you can try to use a faster library if JSON encoding / decoding is performance critical on your application.

Or you could try something like Apache Arrow or Flexbuffers?

If you write off the "JSON", sure, there's a bajillion options. But that's not always possible or desirable. None of those bajillion options have the combination of support and mindshare that JSON has obtained, for better or worse.

We're talking differences of a thousandth of a millisecond (0.001ms) for most structs, but yes.

encoding/json from stdlib makes a lot of allocations (~30) due its use of reflection, which is notoriously slow.