5 ms·

Techempower benchmarks beg to differ. https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=query https://www.techempower.com/benchmarks/#section

Techempower benchmarks beg to differ. https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=query 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.

TheDong 5y ago
It seems to me like the go ecosystem would rather have a less performant language if it means more similar code between projects. 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.
- sofixa 5y ago
  > 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.
  - TheDong 5y ago
    They exist (fasthttp and fastjson for example), but no one actually uses them. 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?
    - riwsky 5y ago
      People do use them, though. Look through the fastjson dependents on GitHub[1] and you'll find serious projects from the Kubernetes special interest groups and various blockchains. Heck; elastic even built their own for beats[2]. There's no big philosophy difference here. Most go programmers choose encoding/json over fastjson for the same reason most Jackson programmers choose databind over streaming: it's a simpler API. [1]: https://github.com/valyala/fastjson/network/dependents?dependent_type=PACKAGE&package_id=UGFja2FnZS0yMjY0ODM5MDQ3 https://github.com/valyala/fastjson/network/dependents?depen... [2]: https://github.com/elastic/beats https://github.com/elastic/beats
    - neodon 5y ago
      https://github.com/valyala/fasthttp https://github.com/valyala/fasthttp It has 16.8k stars. Is that good?
    - konart 5y ago
      >but no one actually uses them. 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.
    - lelanthran 5y ago
      > 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. 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.
raggi 5y ago
Sure, but also no one should be benching servers with 'ab' either...
- sinsterizme 5y ago
  Why’s that?
  - raggi 5y ago
    because for many servers, ab taps out before the servers do

TheDong 5y ago

It seems to me like the go ecosystem would rather have a less performant language if it means more similar code between projects. 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.

sofixa 5y ago
> 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.
- TheDong 5y ago
  They exist (fasthttp and fastjson for example), but no one actually uses them. 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?
  - riwsky 5y ago
    People do use them, though. Look through the fastjson dependents on GitHub[1] and you'll find serious projects from the Kubernetes special interest groups and various blockchains. Heck; elastic even built their own for beats[2]. There's no big philosophy difference here. Most go programmers choose encoding/json over fastjson for the same reason most Jackson programmers choose databind over streaming: it's a simpler API. [1]: https://github.com/valyala/fastjson/network/dependents?dependent_type=PACKAGE&package_id=UGFja2FnZS0yMjY0ODM5MDQ3 https://github.com/valyala/fastjson/network/dependents?depen... [2]: https://github.com/elastic/beats https://github.com/elastic/beats
  - neodon 5y ago
    https://github.com/valyala/fasthttp https://github.com/valyala/fasthttp It has 16.8k stars. Is that good?
  - konart 5y ago
    >but no one actually uses them. 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.
  - lelanthran 5y ago
    > 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. 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.

raggi 5y ago

Sure, but also no one should be benching servers with 'ab' either...

sinsterizme 5y ago
Why’s that?
- raggi 5y ago
  because for many servers, ab taps out before the servers do