Hacker News Reader

Comment by sofixa | Hacker News Reader

> 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.

View on HN

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

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?

>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.

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?depen... [2]: https://github.com/elastic/beats

> 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.

https://github.com/valyala/fasthttp

It has 16.8k stars. Is that good?

Reply on news.ycombinator.com