Techempower benchmarks beg to differ.
https://www.techempower.com/benchmarks/#section=data-r20&hw=...
There's a lot of Java above the first occurrence of Go. Also - nobody writes Java web applications using the Sun httpserver. It's verbose and old.
https://www.techempower.com/benchmarks/#section=data-r20&hw=...
There's a lot of Java above the first occurrence of Go. Also - nobody writes Java web applications using the Sun httpserver. It's verbose and old.
Take for example json: Go's stdlib json implementation is wildly slow. It has to be implemented in reflection, it can't use any code-generation anything, and for backwards compatibility it can never trim any feature, no matter whether it has a performance implication for all users of the package. It's well known to be a slow implementation.
In java, json isn't part of the stdlib. There's jackson if you want one flavor of fast json, jetty ships its own json serializer, etc. This means that if you pick up a new java codebase written in a different framework, it's possible you have to learn the right pattern to json serialize things.
By nature of these third party libraries in java being out of the stdlib, they've been able to grow and become more performant and compete with each other.
Go sits on the opposite side. The stdlib http implementation is a little slow. The stdlib json implementation is incredibly slow. No one wants to build these features outside of the stdlib though, and people would rather every codebase have the same looking go code, even if that means the actual code itself is slower.
What? There are multiple json parsing and http server implementations for Go.
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?
[1]: https://github.com/valyala/fastjson/network/dependents?depen... [2]: https://github.com/elastic/beats
It has 16.8k stars. Is that good?
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.
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.
Java has a library ecosystem that is stable but not ideological, unlike golang.
I think of golang as the opposite of "The Curse of Lisp" [1], wherein its so standard that it can't fit the evolutionary cracks as well as a less opinionated framework. The ugliness of Java has been its strength. Whether it's Hotspot or ZGC or arch support or whatever, the JVM bytecode and rather limited capabilities of the language forced more focus on the objective quality of the artifacts of the language rather than the language itself. A lot of those artifacts continue becoming more impressive over time.
[1] http://www.winestockwebdesign.com/Essays/Lisp_Curse.html