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 <$Revision: 655654 $>
    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 2000 requests
    Completed 3000 requests
    Completed 4000 requests
    Completed 5000 requests
    Completed 6000 requests
    Completed 7000 requests
    Completed 8000 requests
    Completed 9000 requests
    Completed 10000 requests
    Finished 10000 requests


    Server Software:        
    Server Hostname:        localhost
    Server Port:            8000

    Document Path:          /
    Document Length:        1048576 bytes

    Concurrency Level:      100
    Time taken for tests:   10.085 seconds
    Complete requests:      10000
    Failed requests:        0
    Write errors:           0
    Total transferred:      10489017384 bytes
    HTML transferred:       10487857152 bytes
    Requests per second:    991.62 [#/sec] (mean)
    Time per request:       100.846 [ms] (mean)
    Time per request:       1.008 [ms] (mean, across all concurrent requests)
    Transfer rate:          1015729.90 [Kbytes/sec] received

    Connection Times (ms)
                  min  mean[+/-sd] median   max
    Connect:        1    2   0.8      2       6
    Processing:    21   99   5.6     98     137
    Waiting:        1    3   2.7      2      41
    Total:         25  101   5.6    101     139

    Percentage of the requests served within a certain time (ms)
      50%    101
      66%    102
      75%    103
      80%    103
      90%    105
      95%    106
      98%    108
      99%    112
     100%    139 (longest request)
     

Secondly, node.js:

    $ ab -c 100 -n 10000 http://localhost:8000/
    This is ApacheBench, Version 2.3 <$Revision: 655654 $>
    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 2000 requests
    Completed 3000 requests
    Completed 4000 requests
    Completed 5000 requests
    Completed 6000 requests
    Completed 7000 requests
    Completed 8000 requests
    Completed 9000 requests
    Completed 10000 requests
    Finished 10000 requests


    Server Software:        
    Server Hostname:        localhost
    Server Port:            8000

    Document Path:          /
    Document Length:        1048576 bytes

    Concurrency Level:      100
    Time taken for tests:   15.765 seconds
    Complete requests:      10000
    Failed requests:        0
    Write errors:           0
    Total transferred:      10487558651 bytes
    HTML transferred:       10486808576 bytes
    Requests per second:    634.31 [#/sec] (mean)
    Time per request:       157.653 [ms] (mean)
    Time per request:       1.577 [ms] (mean, across all concurrent requests)
    Transfer rate:          649639.92 [Kbytes/sec] received

    Connection Times (ms)
                  min  mean[+/-sd] median   max
    Connect:        0    1   1.7      1      11
    Processing:     2  156  34.7    159     272
    Waiting:        1   47  29.7     42     136
    Total:          2  157  34.7    161     273

    Percentage of the requests served within a certain time (ms)
      50%    161
      66%    174
      75%    182
      80%    187
      90%    198
      95%    209
      98%    221
      99%    227
     100%    273 (longest request)

Not only does go serve the traffic more quickly, but it also has a much lower standard deviation between slow and long requests. Impressive.

Benchmarking on macbooks is often an exercise in testing the mediocre default configuration of the network stack, not your language. My macbook pro gets 4k rps with apache, node, go, and nginx. YMMV and all that, but I'm always wary.

What configs do you change?

I usually just benchmark in a production environment.

Clarification.

What did you change to get the claimed 4k rps on your Macbook?

Upgraded from air to pro ;)

I'd be interested to see your numbers benchmarking with `siege' rather than `ab'.

I really love 'siege'. I wonder if you can get it show you response-time percentiles (or whatever they're called). I mean this (from `ab`):

    Percentage of the requests served within a certain time (ms)
      50%    161
      66%    174
      75%    182

wrk or weighttp are my preferred tools.

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.

check the memory usage. When I did the comparison, the node server's memory climbed steadily up to about 50MB, while the Go server's memory stabilized at about 17MB.

It'd be interesting to throw Erlang into the mix, too.

One example:

http://eric.themoritzfamily.com/websocket-demo-results-v2.ht...

Has Node.js, Erlang, Scala, go and a lot of Python. On EC2 Erlang and Java pretty much blow everything else out of the water.

In the comments of the article are some test results too, only that on that test, nodejs was slightly faster.

fyi, in the replies of the original post someone got totally different results. with v0.6 it was significantly faster than Go and with 0.8 was on the same level

Unless he went out of his way to use x86, I can't imagine he's not using x86-64. x86-64 has traditionally been the arch that Go has gotten the most attention on anyway, it is what everyone uses these days.

> I can't wait until all the current methods of creating web apps are obsolete.

Please, don't hold your breath.

Can anyone from Stripe confirm that this box is not rooted?

Confirmed.

Aw, sad. The server seems to be non-responsive.

Read this if you're stuck on level 3: http://destroy.net/machines/security/P49-14-Aleph-One

<3

I read this back in college, ages ago. Still relevant - not quite up there with K&R as far as technical writing goes, but it does indeed do the job of making a theoretical problem into an understandable & exploitable one, and for that reason "Smashing the Stack For Fun And Profit" is a phrase that has a special place in my heart.

Thanks for that link. Reading through one of the first sections about pushing parameters to the stack, I noticed the call:

gcc -S -o example1.s example1.c

However, example1.s looks very different on Mac than on Linux, in particular, on Mac the parameters are pushed in reverse order:

Leh_func_begin2: ...

        movl    $1, %eax
        movl    $2, %ecx
        movl    $3, %edx
        movl    %eax, %edi
        movl    %ecx, %esi
        callq   _function

Whereas on Linux, they are pushed in the order specified in that link:

        movl    $3, %edx
        movl    $2, %esi
        movl    $1, %edi
        call    function

What is the reason behind this? Is it that the stack on OS X is implemented to grow up instead of down?

> 1) Every artist who's made an online release of their content in a desirable format (without DRM, etc) has seen sales in proportion to their general popularity. Every single one, without even one exception.

That's not true. Radiohead pulled the plug on their In Rainbows experiment after only 3 months in 2007. They decided to go the more traditional route instead. Why would they (an incredibly popular band) do something like that if sales were truly in proportion to their popularity?

What you are claiming is not true. Here are some sources that refute your claim:

http://en.wikipedia.org/wiki/In_Rainbows#Sales_and_chart_pla...

In October 2008, a report from Warner Chappell revealed that although most people paid nothing for the download, pre-release sales were more profitable than the total money from sales of Hail to the Thief. The report also stated that the discbox sold 100,000 copies.

And yet they haven't repeated this with subsequent releases. Why not? I really don't know. My guess is that they think this was a one-time gimmick and not a repeatable model.

I could be wrong. I hope I'm wrong.

Do you have a link for this "pulled the plug" assertion? It's my understanding that Radiohead always intended to release the CD in stores all along because "some fans would not have the technological means to obtain the new material." according to Wikipedia.

Yes, they do still believe in traditional distribution to a point (after giving it away for three months), but I think it's unfair to characterise it as a failure.

He's suggesting that because Radiohead eventually took down the page, the experiment was a failure. He's conveniently ignoring the fact that their online opt-in pay system generated more revenue than their last published album before they dismantled it, demonstrating that demand/revenue in the new model exceeded the old.

I do have a link to cite: http://www.nme.com/news/radiohead/40444

Failure is a subjective term. Radiohead released their next album at a fixed price with a rollout into traditional formats as well.

Radiohead tried a similar experiment to Louis C.K.'s back in 2007 with their album In Rainbows. But after 3 months they decided that the online sales weren't working out and that they should pursue the more traditional avenue of selling CD's out of retail stores. Two similar stories with vastly different outcomes.

I say that it's similar because both are well established acts in the entertainment industry, releasing their work unencumbered by DRM (or other encryption) via a website. As I see it, the main differences are (in very general terms):

- Radiohead said that fans could pay whatever they wanted for the album, Louis C.K. charged $5 - Radiohead are a band, Louis C.K. is a comedian - Radiohead tried it in 2007, Louis C.K. in 2011

Of these 3, the most significant difference that I see is that Radiohead didn't set any price tag on their work while Louis C.K did. By some estimates more than half of the people who downloaded In Rainbows did so without paying a penny for it. Louis C.K., on the other hand, charged $5 right up front. The price tag was so low that it was a pretty easy decision for most who bought it, but it was there nonetheless.

I think that speaks volumes about setting customer's expectations appropriately, an area in which the software industry traditionally shoots itself in the foot. Ask your customers to pay something. If you have something of value, they will.

That's a nice story about Radiohead but it isn't true. In fact, Radiohead's online release of In Rainbows was a smashing success and generated more money in opt-in online sales than their entire previous album. Cite:

http://www.nme.com/news/radiohead/40444

http://en.wikipedia.org/wiki/In_Rainbows#Sales_and_chart_pla...

tl;dr: If you think that

  var output = Sugarless(input)(
     sanitize          
   , trim             
   , truncate, "", 200   
  );

is more readable than

  var output = truncate(trim(sanitize(input)), 200)

than you may be interested in Sugarless. Call me old school, but I prefer the latter.

Yeah, that looks confusing as heck.

Also, if I can't tell the difference between a comma and a period on your _improved language syntax_ homepage, then you're doing something wrong.

What about something like this:

  fn = compose(truncate.flip().curry(20), trim, sanitize);
  output = fn(input);

Better or worse?

Better, since it is clear how to pass a function as an argument.

> Which is exactly what the fat arrow does in Coffeescript.

Except when there's a regression in the compiler, and then it doesn't.

https://github.com/jashkenas/coffee-script/issues/1842

It's all good though, because "Pull requests are always welcome." :P

Yes -- that needs to be fixed pronto, and a 1.1.4 release cut -- which should include both that patch and a fix for Node 0.6's inconsistent "fs.watch" behavior.

Hah, touche. Okay, I'll clarify - $.proxy and => are functionally equivalent in my locally installed version of Coffeescript. :P

That regression is now fixed here: https://github.com/jashkenas/coffee-script/issues/1842#commi...

Glad to see that http://wastm2released.com/ was updated to reflect this announcement! Congrats on being so close Allan!