Ruby 2.1.1 is released and Ruby turns 21

And this is _not_ a property of native vs. green threading. (And shows how shallow the comparison is, given the number of languages that implement green threads mapped to native threads nowadays.)

So?

> no, I disagree with you - multithreading is not an implementation detail.

Threading is a language feature, not an implementation detail. Whether threads are implemented by way of native threads on the underlying platform (as in JRuby, current CPython or MRI), or green threads in the runtime (as in old MRI, etc.), and, in the latter case, whether the green threads are mapped to native threads on an N:1 (as in old MRI) or M:N (as in the main Erlang implementation) model are implementation details.

> For example Python has the notion of destructors in the language, the reference implementation having a GC based on reference counting, so when implementing it on top of the JVM/CLR or whatever platform that doesn't do reference counting, that's at least one feature that can't work.

Sure, it could, since you could obviously (at the cost of making interop harder) write a Python implementation with its own garbage collector that ran on the JVM or CLR. You might choose to sacrifice portability for better interop with the languages the platform was designed for, but that's a choice.

> Django that says it runs on Jython but nobody mentions that Django needs the MySQL client written in C and won't work with the pure version

Seems to me that's a problem either with Django or the pure python MySQL driver, but not with the Python language.

> Anybody that is fantasizing about Python having a usable implementation other than CPython is delusional.

Perhaps; I'm less familiar with Python's other implementations than with Ruby's (particular JRuby) which is definitely usable, and definitely uses native threads without a GIL.