4 ms·

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 s

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.
- abernard1 5y ago
  Obviously what you say is true, but there is a cultural element to this. 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 http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

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.
abernard1 5y ago
Obviously what you say is true, but there is a cultural element to this. 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 http://www.winestockwebdesign.com/Essays/Lisp_Curse.html