Go as an alternative to Node.js for Very Fast Servers • Hacker News Board

Re: Go as an alternative to Node.js for Very Fast Servers

#101

Post by saidajigumi » Sat, Feb 23, 2013, 1:15 AM UTC

hrwl wrote: post #12

I have never understood the focus on speed as a selling point for Node. It may well be very fast, but it seems to me that the primary selling points would be the ability to share code between client and server and that you can start coding server side without learning a new language if all you know is JavaScript.

First off, while some sharing between client and server happens, that tends to be an edge case in my experience. The roles of client and server, and APIs available to each, are rather different. I.e. the environment of the browser and node.js server aren't homogenous.

Second, "start coding in XXX without learning a new language" is a terrible selling point. I've seen this thinking appeal to misguided PHB-types and witnessed the result: immense organizational damage. In my experience, this isn't a necessary or sufficient selling point to good developers. Learning a new language just isn't that hard, and a big part of a shift like this is actually in learning the new environment's paradigms, APIs, and best practices.

To make the latter point more strongly: if you're having doubts about your ability to pick up a new language, definitely take some time to learn a few new languages. Do a tutorial, play with a few small projects, enough to get the flavor of the language. Your hackery will benefit immensely from this, even when you return to your primary language.

Re: Go as an alternative to Node.js for Very Fast Servers

#102

Post by cgh » Sat, Feb 23, 2013, 2:10 AM UTC

VeejayRampay wrote: post #64

jlgreco wrote: post #58

Earlier quoted context omitted.

> For some reason people still hate the language even though it's the closest to being the most versatile language around (in every single aspect that makes a good language it ranks well against the others) In every respect that a PHB may care about, perhaps. I think you should examine that "for some reason" more carefully before declaring that all reasons favor Java. Clearly there is something going on there, unless…

Let me clarify then: I think that a consensus was built in the mid-90s that Java was a pain in the ass and not an improvement over what was available in that particular field at the time (not as easy as other higher-level languages and not as good or fast as C or C++). I have a feeling that people over time consolidated that consensus through some form of confirmation bias even though the Java/JVM ecosystem had made…

It's not the JVM or the ecosystem, but the language itself. It is clunky and generally irritating to write and read. But the libraries and its niche sophistication (basically enterprise middleware and webapps) are second to none, so people put up with it.

Note: I've been writing it professionally since 1999, currently working a lot with ServiceMix so I'm knee-deep in the enterprise stuff.

Re: Go as an alternative to Node.js for Very Fast Servers

#103

Post by mfenniak » Sat, Feb 23, 2013, 2:42 AM UTC

babuskov wrote: post #100

Is there a socket.io equivalent for Go? In terms of ease of use and at least providing the same functionality.

Looks like there are a couple packages that would solve this problem, but neither appear to be production ready or up-to-date.

https://github.com/madari/go-socket.io

https://github.com/igm/sockjs-go/

Re: Go as an alternative to Node.js for Very Fast Servers

#104

Post by [deleted] » Sat, Feb 23, 2013, 3:48 AM UTC

mfenniak wrote: post #103

babuskov wrote: post #100

Is there a socket.io equivalent for Go? In terms of ease of use and at least providing the same functionality.

Looks like there are a couple packages that would solve this problem, but neither appear to be production ready or up-to-date. https://github.com/madari/go-socket.io https://github.com/igm/sockjs-go/

[deleted]

Re: Go as an alternative to Node.js for Very Fast Servers

#105

Post by e12e » Sat, Feb 23, 2013, 4:08 AM UTC

tel wrote: post #80

papsosouid wrote: post #17

Earlier quoted context omitted.

Can I ask what language you are used to? I hear how nice go is as a language a lot, but coming from haskell, go is hideous in comparison.

Here's a comparable Haskell server, warts and all {-# LANGUAGE OverloadedStrings #-} import Snap import qualified Data.ByteString as BS main :: IO () main = httpServe (setPort 8000 emptyConfig) $ writeBS $ BS.replicate (1024*1024) 100 I'm benchmarking it currently, but my laptop's network stack seems to break ab. It's also probably faster to build the response incrementally using an Enumerator, but I've never used Sn…

I tried this, the other Haskell version, and the go and node version from op -- with some rather ridiculous ab-values -- the end result was that both of the haskell versions crashed after around 8k requests, while both the go and node-versions completed -- with no missed requests.

I don't have the full numbers (didn't log them) -- but running "ab -n 100000 -c 1000 http://localhost:8000/ -- nodejs completed in 160 seconds, go in 170 seconds. Nodejs had a few requests around 8 seconds, and go had a worst time of almost 5 seconds. (This is on an old desktop, with a core 2 duo - roughly 6000 "bogomips" pr core, two cores).

I'm guessing the haskell solutions ran out of resources, but I'm not sure.

Re: Go as an alternative to Node.js for Very Fast Servers

#106

Post by e12e » Sat, Feb 23, 2013, 4:13 AM UTC

jamwt wrote: post #91

Here's a haskell comparison (hint: it does very well). https://gist.github.com/jamwt/5017172 Haskell was ghc 7.6.1 with ghc --make -O2 Go is go1.0.2 with "go build".

As noted above - with ridiculously large values for ab this one crashes (although I didn't compile with O-parameters). I think this (and the other haskell solution) ran out of resources.

Both the go and nodejs versions completed without problems.

I was a little disappointed -- I was actually hoping I'd see comparable performance -- even if it is a silly test.

I think it is interesting that simple, idomatic code in go and nodejs didn't crash -- not sure what assumptions might be "wrong" in the underlying haskell code (I'm guessing if anything should be "fixed" it is in the web server libraries used).

Re: Go as an alternative to Node.js for Very Fast Servers

#107

Post by tel » Sat, Feb 23, 2013, 4:56 AM UTC

e12e wrote: post #105

tel wrote: post #80

Earlier quoted context omitted.

Here's a comparable Haskell server, warts and all {-# LANGUAGE OverloadedStrings #-} import Snap import qualified Data.ByteString as BS main :: IO () main = httpServe (setPort 8000 emptyConfig) $ writeBS $ BS.replicate (1024*1024) 100 I'm benchmarking it currently, but my laptop's network stack seems to break ab. It's also probably faster to build the response incrementally using an Enumerator, but I've never used Sn…

I tried this, the other Haskell version, and the go and node version from op -- with some rather ridiculous ab-values -- the end result was that both of the haskell versions crashed after around 8k requests, while both the go and node-versions completed -- with no missed requests. I don't have the full numbers (didn't log them) -- but running "ab -n 100000 -c 1000 http://localhost:8000/ -- nodejs completed in 160 sec…

Not sure, I'm trying to replicate it but I'm having a tough time with OSX's network stack. I can't siege or ab very well. The Haskell server tends to stay under 6Mb on my machine though. I'll keep stressing it.

http://imgur.com/b89bxST

Re: Go as an alternative to Node.js for Very Fast Servers

#108

Post by kintamanimatt » Sat, Feb 23, 2013, 5:58 AM UTC

mjijackson wrote: post #39

I was curious, so I actually ran both of the servers from the article on my little MacBook Air. The results are below. First, go: $ ab -c 100 -n 10000 http://localhost:8000/ This is ApacheBench, Version 2.3 Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 1000 requests Completed 200…

I did this test a while ago on my laptop running Linux Mint. With higher concurrency levels (IIRC, about 1k simultaneous connections), I saw just the opposite, with cracks starting to show and Go performing worse than Node, although the V8 engine did consume more memory.

Re: Go as an alternative to Node.js for Very Fast Servers

#109

Post by microtonal » Sat, Feb 23, 2013, 6:46 AM UTC

e12e wrote: post #105

tel wrote: post #80

Earlier quoted context omitted.

Here's a comparable Haskell server, warts and all {-# LANGUAGE OverloadedStrings #-} import Snap import qualified Data.ByteString as BS main :: IO () main = httpServe (setPort 8000 emptyConfig) $ writeBS $ BS.replicate (1024*1024) 100 I'm benchmarking it currently, but my laptop's network stack seems to break ab. It's also probably faster to build the response incrementally using an Enumerator, but I've never used Sn…

I tried this, the other Haskell version, and the go and node version from op -- with some rather ridiculous ab-values -- the end result was that both of the haskell versions crashed after around 8k requests, while both the go and node-versions completed -- with no missed requests. I don't have the full numbers (didn't log them) -- but running "ab -n 100000 -c 1000 http://localhost:8000/ -- nodejs completed in 160 sec…

Because this isn't the same benchmark, did you compile with -O2? The Go version allocates a 1MB slice once and sends it to every user. The Haskell version literally states that it should make a bytestring during every request. The compiler might optimize it away with the right flags.

Re: Go as an alternative to Node.js for Very Fast Servers

#110

Post by microtonal » Sat, Feb 23, 2013, 7:40 AM UTC

microtonal wrote: post #109

e12e wrote: post #105

Earlier quoted context omitted.

I tried this, the other Haskell version, and the go and node version from op -- with some rather ridiculous ab-values -- the end result was that both of the haskell versions crashed after around 8k requests, while both the go and node-versions completed -- with no missed requests. I don't have the full numbers (didn't log them) -- but running "ab -n 100000 -c 1000 http://localhost:8000/ -- nodejs completed in 160 sec…

Because this isn't the same benchmark, did you compile with -O2? The Go version allocates a 1MB slice once and sends it to every user. The Haskell version literally states that it should make a bytestring during every request. The compiler might optimize it away with the right flags.

I tried the benchmark as in the article, and the above Haskell compiled with '-O2'. With Go I usually get around 1320 reqs/second, with Snap around 1100. Both using four threads.

With a single-threaded Warp instance, I could get around 1350 reqs/seconds, though it failed dramatically when I used more threads.