I don't see any point in comparing a production quality web server with python's stdlib web server that is really only to be used for testing. It's not even worth discussing the other issues with this "benchmark".

I know you put effort this and do not want to give you a hard time, but a lot of people on HN will give you a hard time with benchmarks, especially as simple as this, gracious concluding paragraph or not.

Some people here are very dismissive of benchmarking in general, but if you are interested in evaluating programming languages for use in web applications, you would be interested in TechEmpower benchmarks, which are very thorough. [0] You can even send pull requests with updated languages, frameworks, or better implementations of different tests to give more competitive/accurate results. Enjoy.

[0] http://www.techempower.com/benchmarks/ [1] https://github.com/TechEmpower/FrameworkBenchmarks

UPDATE: Fixed link to the benchmarks.

What about using alternative frameworks for HTTP servers for Python? Pointing at only Bottle and going "hey! Python is slower!" is like pointing at WeBRICK and going "Hey! Ruby is slower!" when you haven't even touched Passenger or Unicorn.

What about:

* Flask? http://flask.pocoo.org/

* Tornado? http://www.tornadoweb.org/en/stable/

* Django? https://www.djangoproject.com/

* CherryPy? http://www.cherrypy.org/

What about using PyPy ( http://pypy.org/ ), Jython ( http://www.jython.org/ ) or even IronPython ( http://ironpython.net/ ) instead of plain CPython?

Okay, this is yet another weekly HN "Hello world http benchmark on a Macbook Pro" series. I'd bite. The following Python snippet seems much faster than OP's Go code under the same ab testing.

HTTP server: https://github.com/jonashaag/bjoern

    import bjoern, json


    def home_app(environ, start_response):
      start_response('200 OK', [('Content-Type', 'text/plain')])
      s = {'name': 'A Royal Baby', 'body':'A slow news week'}
      yield json.dumps(s)


    bjoern.run(home_app, '127.0.0.1', 8086)

This isn't Python vs. Go. This is bottle.py vs Go.

While I'm not convinced this is "python" vs "go" (see other comments) what everyone seems to miss is that this is 9 lines vs 23, as well. Ok, so in this test, the performance/line is off by a factor of five (2 times the lines, ten times the performance) -- but it looks to me like the performance could be made up by sticking something like Varnish in front -- so there's really no "real world" performance difference, just more complex code.

I may be wrong, but that's all I see from this. (Assuming architecture >> micro benchmarks)

In related news, I just measured Apples to be 100 times redder than Oranges! What is the point of benchmarking Python vs Go, when by design we all know Python is slower? So, in this particular case it's 100 times, for completely random reasons. Speed is not why I use Python every day and absolutely have no need for Go, although I wish it would magically replace C++.

People might beat up the benchmark or the methods, but in all honesty, Go should be an order of magnitude faster. It's compiled and runs about as fast as java in many benchmarks. I've seen some companies go from ruby to the jvm and have basically said 1 JVM instance = 10 ruby thin instances. So, when you think in that context, it makes total sense that go would be 10x faster than python for the same reasons that a compiled JVM language is 10x faster than ruby.

I'd say from the numbers I've seen this benchmark is not an unreasonable display of the performance difference between go and python.

Google supported Python a while ago. Now, after knocking off its new "Go" toy, started to kick in the nuts the tagged-"lousy kid" Python. Bad attitudes aside, Google would better find another strategy to bolster its offspring. Making a reputation by mocking something else is not something that even a language like Go wants to rely on.

What is the sense of all these Python vs Go runtime benchmarks?

Unless one compares implementations of the same nature, it is obvious that the compiled one, in this case Go, it will always be faster.

Why bother at all to find out the obvious?!

Check out this. Tested by GregBowyer: https://gist.github.com/GregBowyer/6265715

What about not using a framework for python?

I challenge the assumption that being faster is reason enough to check out X.