I should have written "no one wants to use third-party versions of these packages", and I don't think that small semantic issue changes my comment meaningfully.
Do you take issue with the way I'm presenting the go ecosystem other than that small pedantic point?
The two companies I worked in (and still work as of now) both were using fasthttp and non-stdlib json parser (jsoniter and jstream to be exact).
In fact in my experience - nobody uses stdlib implementations outside of projects were stdlib is actually enough (and that's a lot of projects actually) and temp\prototype projects.
[1]: https://github.com/valyala/fastjson/network/dependents?depen... [2]: https://github.com/elastic/beats
No, they don't. But if performance becomes an issue, they can!
> Do you take issue with the way I'm presenting the go ecosystem other than that small pedantic point?
Well, yes, a little. The comparison you're making is presented as "The Java ecosystem has a better outcome than the Go ecosystem". TBH, that's only for performance, and is basically a non-issue if the performance poor.
IOW, you're doing the ultimate in premature optimisation. In the real world, people who run into performance problems will a) run into them sooner with Java, and b) solve them the same way in Go.
It has 16.8k stars. Is that good?