In short: money, money, and money.
Ruby has what, a handful (if that?) of people at Heroku who work on Ruby some of the time? Not sure if Matz does full-time or not.
Ruby has what, a handful (if that?) of people at Heroku who work on Ruby some of the time? Not sure if Matz does full-time or not.
There's actually been a bunch of great performance increases in the past few years in addition to the GC. Optimized method cache invalidation by the late James Golick, frozen string pool for hash keys by tmm1, using vfork instead of fork, etc, copy on write GC. There's also new features, like Ruby's ability to GC symbols that let developers use symbols in more places and spend less time converting back and forth between strings.
So yes, money is a factor. Having employees work on it full time helps. Despite only having 3 full time employees Ruby has made some pretty impressive improvements recently.
Holy shit, how did I miss this?
edit: more details here: https://news.ycombinator.com/item?id=8804624
That's really sad...good guy
And embrace types, either optional or inferenced. Optimize on type information.
v8 doesn't really do multithreading, for example, so it's able to take a lot of shortcuts that save a lot of time. v8 doesn't have built-in Bignum support, and doesn't support non-UTF-16 character encodings, so there is a lot of work that it doesn't have to do, where more full-featured languages have to make sanity checks and do conversions under the hood frequently. Ruby's metaprogramming constructs are extremely powerful, but their rulesets are fairly complex, so the VM has a lot of bookkeeping to do to ensure that everything works well. I don't know Python's internals that well, but I do know that Ruby spends a lot of time making sure that all those things play nicely together without the programmer having to exert much effort, and that does incur a performance penalty.
v8 is an absolutely excellent piece of engineering, but it's a tool that occupies a slightly different problem space than the Ruby and Python VMs do. That's not to say that Ruby and Python don't have gains they can and should make, but that it's not as simple as pouring money in one end and watching performance come out.
If you need multiple, separate VMs (ie, to drive multiple isolated scripting engines in a game), then v8 isolates or Lua contexts will do you just fine, but that's a different use case than most places where you'd want to use concurrent Python.
https://docs.python.org/2/extending/embedding.html
It's just that at the time Python was created, multithreading was not something you generally did in a C program. The POSIX thread standard didn't come out until 1996. Python was started in 1989, first released in 1991, and reached 1.0 in 1994. Common rules of thumb for dealing with multithreaded programs (eg. "Avoid global or static data") didn't really become popularized until the 2000s, and many programmers in less well-informed circles still don't know them.
Not really. Basically on par.
Maybe my information is out of date, but I just now picked a random benchmark (the fasta one from the language shootout) and ran it against v8-3.14.5.10 and luajit-2.0.3 (Fedora 21, latest available via yum), and luajit came out quite a bit ahead. I grant that it's a really naive benchmark setup and shouldn't be taken seriously, but my investment here is pretty minimal :)
$ time luajit-2.0.3 fasta.lua 25000000 > /dev/null
luajit-2.0.3 fasta.lua 25000000 > /dev/null 8.60s user 0.01s system 100% cpu 8.613 total
$ time d8 --nodebugger fasta.js > /dev/null -- 25000000
d8 --nodebugger fasta.js -- 25000000 > /dev/null 12.80s user 0.51s system 100% cpu 13.209 total
Those are in the same order of magnitude even! Not even 2x the speed. Hardly makes a difference in picking one or the other, all other things being the same.
Now, compare V8 or LuaJit with Python or Ruby -- that would be "wrecking it".
I'm not attacking v8 here. I'm simply pointing out that there are VMs for interpreted languages which run faster than v8, which isn't to say "v8 is bad", but rather "different languages inherently have different performance profiles".
Though I must admit V8 could handle dictionaries a bit better - but at the moment it does not.
There are a bunch of core contributors that are very active. Several of their companies allow them to spend time contributing (most of them are from Japan). Another example is Aaron, he is on Ruby core and his company allows him some time to contribute to open source, so this is sponsorship in a way. I while a company stands to benefit from sponsoring a full time developer, they benefit just as much if someone else sponsors a full time developer. Right now there's not enough companies with either a business incentive, altruism, or interest. Perhaps there are companies out there interested in sponsoring full time devs who just don't know how (and to your point cannot find them) but I think that would be the minority case.
> Oracle Labs pays two people full time (including me) [to work on JRuby] and a PhD student, and more soon.