Why bytedance/sonic?

[alecholmez]

Description

What exactly did this library gain from including this library? #3184
From my quick look at it, it requires CGO? goccy/go-json is already really fast and a pure go implementation. It seems like there was no real value add proposal for this libraries integration and it was just ushered in.

Note:
https://github.com/bytedance/sonic#compatibility

Sonic DOES NOT ensure to support all environments, due to the difficulty of developing high-performance codes. For
developers who use sonic to build their applications in different environments (ex: developing on M1 Mac but running on linux server), or those who want to handle JSON strictly consistent with encoding/json, we provide some compatible
APIs as sonic.API

Does this means that gin web severs are no longer ARM compatible? Seems a bit odd for a web framework. Folks generating code with oapi-codegen automatically inherit this dependency regardless of using gin or echo. Seems like unwanted behavior to me.

[arp242]

Does this means that gin web severs are no longer ARM compatible?

No; it's only used if you add the sonic and avx build tags, and then only on supported platforms.

That said, a JIT in gin (even if disabled by default) seems rather unexpected to me. It's in a stable release so can't really be changed now, but IMHO a gin.SetJSONDecoder(someInterface) or something along those lines would have been much better instead of piling on JSON libraries.

[otcirtan]

I don't trust bytedance. Did you see the size of this thing? And it generates machine code?

I'm going to stop upgrading gin, and probably move away from it.

[alkiller22]

I don't trust bytedance. Did you see the size of this thing? And it generates machine code?

I'm going to stop upgrading gin, and probably move away from it.

Agree, use github.com/cloudwego/hertz as a better solution

[q5p]

I believe that neither the question nor the replies are constructive, I think closing this up is a good idea.

[PureWhiteWu]

@otcirtan Bytedance also contributes to the linux kernel. Please move away from linux. DON'T use anything bytedance contributed to.

[jizhuozhi]

I don't trust bytedance. Did you see the size of this thing? And it generates machine code?

I'm going to stop upgrading gin, and probably move away from it.

Personal subjective emotions (more strictly speaking, discrimination) should never be brought into the discussion of technical solutions in the open source community.

[otcirtan]

What's subjective about a huge increase of the attack surface for very modest gains and the influence of the CCCP? May I also note that the original questions have not been addressed, let alone answered satisfactorily?

discrimination

It's only discrimination in the original, literal sense: "recognition and understanding of the difference between one thing and another: discrimination between right and wrong".

[frankli0324]

oh great, here comes not only discrimination, but also f**king politics. I agree that we should close this issue.

the original questions have not been addressed

question: Does this means that gin web severs are no longer ARM compatible?

No; it's only used if you add the sonic and avx build tags, and then only on supported platforms. by @arp242

no real value add proposal for this libraries integration and it was just ushered in

it adds an option to use a faster json library on specific(widely used) platforms. I see that as an improvement (by myself)

oh,

influence of the CCCP

LOL

[jizhuozhi]

@otcirtan So you can distrust any json library of choice and just support encoding/json (maybe you can trust Google). But if Gin uses any other json library we can say don't trust the other technologies it uses (I think CGO will bring attack surface).

What's subjective about a huge increase of the attack surface for very modest gains and the influence of the CCCP?

In your words it is very subjective to attack companies that actively participate in open source contributions. As you said, maybe you should stop using Go, and stop using Linux (as @PureWhiteWu said), because there is too much code contributed by Bytedance.

I agree that we should close this issue.

[Leo-stone-dot]

I don't trust bytedance. Did you see the size of this thing? And it generates machine code?

I'm going to stop upgrading gin, and probably move away from it.

It would be more helpful if you can provide another high-performance library.

[alecholmez]

Our consumption of the oapi-codegen tool no longer bundles this dependency into the go.mod as a transitive dep. So this issue is no longer relevant regardless of the politics above. Thanks for closing @appleboy