Hacker News Reader

Comment by rartichoke | Hacker News Reader

That test is rigged to be a best case scenario for Go. How often do you send 1MB responses down to the client?

If you send 3KB responses then you would see both setups are much closer in performance.

Factor in some actual I/O and the difference will be even less. Then you'll eventually realize using either one makes little difference when it comes to performance.

This is why micro benchmarks are pure jokes. A real world site has a mix of response sizes, database I/O and caching. It's the only way to test something properly and you'll see if you properly test both there will be little difference in performance.

View on HN

Original author of the post in question here.

Please note that the microbench was "rigged" by the author of Node when he was first presenting it several years ago (spelled out in the article).

If you need a tl;dr, it's this: I don't care for JavaScript as a language. Many make the argument that JavaScript should be adopted widely server-side because of its speed. I assert that languages should be evaluated not only for performance but for maintainability, feature sets, standard library, etc. Go provides a great combination of execution speed, development speed, and ease of maintainability.

The development speed isn't very good with Go because you have to re-invent almost everything yourself because the web libs are seriously years behind other platforms.

The default template language is also really archaic and no one has created a solid alternative yet that's actually well tested and used by the masses.

It might have good execution speed and the language itself might be nice but the only thing that matters is going from point A to point B. Go will not get you there faster than other languages and the execution speed is a non-issue for pretty much every platform (even rails) if you use tools available to you to their fullest.

P.S., I compared Go to Node almost a year ago and even wrote a mini framework for Go to resemble a smaller version of Express. I eventually just said fk it and stopped because the gains were not even close to being worth it.

My understanding is that many people try Go and decide they don't like it, as you did; at the same time, many have experiences that are similar to mine and they embrace it. To each his own.

The word "rigged" in your original comment implied dishonesty on my part. I just wanted to clarify that the JS code used in the microbench was Ryan Dahl's, and mine was just a port to Go. I was merely giving Go the same task that he did.

I did like it, what I didn't like was solving common web app related issues that were solved on other platforms years ago. That's what completely killed my urge to consider Go.

I don't want to spend most of my time solving boring issues. I want to spend most of my time writing features for apps I make. Being productive makes me happy but everyone has different happiness triggers I suppose.

I see performance as a somewhat solved problem in 99.999% of the cases so to me a language is not even worth looking at anymore if that's all it offers. I'm not fortunate to be involved in the other 0.001% where easy to do caching might not be enough.

I didn't mean to imply you were dishonest. I just wanted to point out that sending out 1MB responses is kind of silly.

It took me like 2.5 years of messing around to finally realize all I care about is being able to take an idea and turn it into working code that's maintainable and scales good enough for the time being.

may I ask, what exactly did you have to re-invent? It's true that Go is very young and so are the libreries, and that only recently has started to be seen as web language. But my experience is that the most common problems for web are solved with things like Revel. Is true that is a bit feature basic and there are not that many other options, but I wouldn't consider it insufficient.

To be fair I didn't use revel. Instead I just used pat (the route mapper) and started to try and recreate most of what express does using go's stdlib because nothing else really existed yet.

The gorilla toolkit's APIs are inadequate and it seemed like quite a few people agreed too because most of them said they rolled their own solutions to do things that certain gorilla libs did but with a more intuitive and friendly API.

Go really isn't that young either. It's been what at least 4 years now? There's no excuse. It's not like the language is 6 months old.

As for re-inventing stuff, it's more so go's ecosystem rather than revel's shortcomings although revel does have its own shortcomings if you were to compare it to something like rails and not express.

Revel seems to be somewhere in between rails and express in terms of opinions which is fine but if it's going to make me less productive then I'm simply not going to use it.

> Go really isn't that young either. It's been what at least 4 years now? There's no excuse. It's not like the language is 6 months old.

1.5 if you count from the first stable release. Which IMHO is what matters, before was just a experiment with a lot of uncertainties. It took ruby 9 years to arrive from 1.0 to Rails. They were other times, sure, but still.

I still consider it very young, or at least I don't know of any other younger language with a better ecosystem.

> Revel seems to be somewhere in between rails and express in terms of opinions which is fine but if it's going to make me less productive then I'm simply not going to use it.

Well, everyone has their preferences, certainly in Go there are not many choices so is not for everyone. But I'd keep an eye on it. Things can change very quickly.

I'll believe it when I see it. Almost nothing has changed since I went through my Go adventure which was like 9 months ago I think.

9 months to me is a huge amount of time. I don't want to have to wait years to be super productive. I want to be super productive right now and by using other platforms I can be.

For a new viable web platform to be accepted it needs to really explode in popularity. It has to offer MASSIVE gains.

Look at node, it offers performance and also offers the benefit of using the same language on both ends. That's pretty neat... maybe, but I think you would at least agree with me that node's popularity and growth has been unmatched. Even so, it's still quite far behind rails and I don't think it will catch up.

I'm not some massive rails fan boy either. I only started using it when 4.0 came out because the ease of caching seemed interesting to me and I was looking for an excuse to go from node/express to something more opinionated just to see if it was more productive.

> but I think you would at least agree with me that node's popularity and growth has been unmatched.

Of course I agree. But node is an unique case, since javascript is not exactly new, and had a trillion people using it when node appeared. You can not expect that to happen again any time soon, unless all main browsers start supporting client-side PHP or something crazy like that.

Go is not 'there' yet, sure, and maybe it'll never be. But its growth can not be judged by node's standards, no really new language could compete then.

For a new language is growing quite good: http://www.google.com/trends/explore?q=golang#q=golang&cmpt=...

Of course this doesn't mean you have to use it, but IMHO it can not be regarded as a failure in anyway.

My point was that even with node's mind boggling growth it still hasn't really overtaken rails when it comes to developer productivity.

I like Go the language; I dislike Go the platform (currently). What's there is great, but there's not enough of it. It's a great 1.0 release: stable, fast, but sparse.

Luckily, Go has a decent head of steam behind it, so when I revisit it in a few years that should be a solved problem ;).

At the very least, calling 50% more lines a "similar line count" is disingenuous. 5 extra lines doesn't look like much, but on a typical multi-thousand line codebase, you're looking at thousands of extra lines.

Right...and you have the benefits of npm with node. AFAIK, there is nothing comparable with Go... and frankly, even the Go code in that terse example takes more lines and isn't as readable (IMHO) as the Node server...

Reply on news.ycombinator.com