Tornado Without a GIL on PyPy STM
I recently read this paper about Julia (http://arxiv.org/abs/1411.1607).  Now when I hear about PyPy I can't help but think about this quote from that paper:    New users also want a quick explanation as to why
    Julia is fast, and whether somehow the same “magic
    dust” could also be sprinkled on their traditional
    scientific computing language. [...]  Julia is
    fast because we, the designers, developed it that
    way for us, the users. Performance is fragile,
    like accuracy, one arithmetic error can ruin an
    entire otherwise correct computation. We do not
    believe that a language can be designed for the
    human, and retrofitted for the computer. Rather a
    language must be designed from the start for the
    human and the computer.

To me, Python and Ruby are both perfect examples of languages that were designed for the human, and ever since have seen extensive effort to retrofit them for fast execution by computers.I respect the work of the PyPy team, particularly given the raving reviews I've seen lately of how RPython is a boon to language designers who can use it to prototype their languages and get a decently-performing VM in not very much time: http://tratt.net/laurie/blog/entries/fast_enough_vms_in_fast...But I can't help but think that languages like Python and Ruby will start to fall to languages like Swift, Julia, Go, etc. that were designed with performance in mind.  I'm not saying this will happen soon, but these languages are showing that you can have your cake and eat it too.I'm not sure how JavaScript and Lua fit into this analysis.  They weren't specifically designed for performance, but have been very successfully optimized.  Lua is a very simple language and Mike Pall is a genius, so LuaJIT has been very successful at speeding up Lua.  JavaScript is a little more complicated, but has received an immense amount of resources into optimizing it, and has also been quite successful at getting fast.