Comment by rartichoke | Hacker News Reader

Comment by rartichoke | Hacker News Reader

Parent Full thread

I still don't see the use case for web app or web game development in Go.

Go ahead and make a mini Go app, re-implement half the features that Express in Node has, then benchmark the 2 with real data using the same data and templates.

Come back when you see that once you start pulling records in from mongodb or somewhere else and start rendering either server side templates with this mongo data or serving json back then the performance differences of the 2 frameworks begin to disappear.

Node will perform better under high concurrency too for most sized responses.

So where's the motivation to switch? If I switch to Go then I have to learn Go + I'm still using Javascript on the front end.

If I stick with Node then I can use my JS knowledge on both ends. This is a really big deal for day to day web app programming and is a deal breaker for html5 games.

Go cannot be taken seriously to be used for web apps until it offers actual performance gains over JS and gets something that lets you write Go but it spits out JS for the client, sort of like Java has GWT (ps. that bombermine mmo uses GWT).

There's also a serious lack of good light weight web frameworks for Go. None of them come close to what Express does for Node, and I'm not the only one who thinks Express is really close to an excellent mix of features without getting in your face.

Node will perform better under high concurrency too for most sized responses.

Can you share evidence supporting this claim?

I tested it with Go v1.0.3 vs Node v0.8.21 + Express v3.1.0

I used mgo with Go to connect to mongodb.

Then I filled it with 1,024 documents that was composed of 2 fields. One field with a few bytes of text and the other with a paragraph of text.

Then I created a few handlers to return:

1) 1x document as json

2) 7x documents as json

3) 15x documents as json

At 15x I decided this was likely going to generate a response large enough that there's no point going higher. It was about 25kb worth of json.

Then I used a lib called "routes": https://github.com/drone/routes

It's not really close to what express does but it's better than nothing. Then I added in my own etag generator using the same method that express does (it gens it off the body length) for responses > 1kb.

Then I benchmarked each route 3 times with ab using: -n 7500 -c {50, 250, 750, 1500}

I ignored the first and averaged the last 2 results.

I did this on a local VM locked down to 1 CPU with 512mb of ram with a c2d 2.13ghz CPU and a 7200 rpm sata HD.

Then I did the same with express using just bodyParser since neither setup had session support. Go didn't have a Redis store that was capable of working with the Gorilla session lib so I didn't use sessions on both setups.

I used the native mongodb driver for node.

Express was for the most part 10-15% faster where faster is more requests per second served. The latency was back and forth. I feel like the latency @ 99% was tighter with Go once the concurrency got really high but the amount was not enough to matter.

For example once I got to the higher concurrencies both were taking a ridiculous amount of time (over 7 seconds) on my old crappy desktop. Loading in 5.5 seconds instead of 7 seconds is not really "better" since it's abysmal on both.

Go is much better at responding with large amounts of data when the database call is eliminated. I can only assume its ability to deal with large strings is leaps and bounds superior to v8 which makes sense to me.

The thing is though, that's pretty much irrelevant. If I was going to serve static content I would be using S3 or nginx. If I'm serving dynamic content then I'm likely pulling this in from a database.

Thank you for the detailed answer.

Go 1.1 (to be released early next month) is across the board faster than 1.03.

The ab tool is not ideal for testing the Go http server because the Go server is not tuned to ab's quirks. Siege might be better.

The mgo client has the most bells and whistles, but it's probably not the fastest client for Go. One of the other clients might perform better.

Why are the Go Redis clients not capable of working with Gorilla? A couple of the clients are well written and are fully functional.

Go is much better at responding with large amounts of data when the database call is eliminated. I can only assume its ability to deal with large strings is leaps and bounds superior to v8 which makes sense to me.

In my own micro-benchmark, I've seen that BSON decoding takes big chunk of time when using mgo. That should explain why the go version got faster when DB access was removed.

This shouldn't come as a surprise as the node.js driver uses a BSON parser written in C++ by default.

It wasn't just a small difference though. The difference between returning 10kb of json from a function vs 10kb of json from mgo was insanely different.

I don't think it's because the bson C++ implementation is so much faster than Go.

I think it's because Go is clearly faster than JS but it doesn't matter once you introduce db calls.

It's sort of like using "for in" vs "for" in JS in the browser. It doesn't really matter which one of them might be faster than the other, as soon as you touch the DOM the difference becomes meaningless and if you jsperf it with DOM touching the results will be the same.

In my mind the big advantage of Go over Node that is sometimes overlooked is that your code in Go is written in a largely serial manner with no callbacks. With Go you don't have to deal with a lot of callbacks when doing I/O since goroutines are multiplexed on the underlying threads.

Reply on news.ycombinator.com