* Threads without GIL (which also requires an explicit memory model)
* concurrency libraries
* Garbage collectors that scale to hundreds of gigabytes worth heap, are parallel and concurrent
* JIT that performs within a small factor of C code
* Tooling support, especially profilers and debuggers are lousy and frequently break in my experience
* bytecode weaving/AST transforms at runtime. The whole refinements thing could have been done more cleanly with callsite and method entry/exit hooking
Talking about MRI here. I know rubinius and JRuby exist and offer some of those features
The creation/creators of Java are not responsible for most of the things you listed. They are attributable to HotSpot, built by the fine folks that brought you the best-of-breed Smalltalk implementation half a decade after Java's release.
HotSpot wasn't released until 1999. Prior to that Java did not have a JIT. Java used to be very slow compared to compiled code and HotSpot was a BIG DEAL when it was released in '99.
GC that scales to hundreds of gb? Do you mean Azul, the proprietary and expensive JVM implementation?
G1GC for dozens of GB, Azul (for now) for hundreds and in the future there'll be Shenandoah.
You're right that those features provided by hotspot. But it is the reference implementation for the JVM after all.
The point remains that the java ecosystem - which includes tooling like eclipse/netbeans/yourkit and JVM implementations - provides the things I've listed that I find lacking in ruby.
Real (presumably, that means native) threads are an implementation detail and not a language feature, and both Ruby and Python use native threads in the current main implementation (and Ruby, and I believe Python, also have implementations that use native threads without a GIL/GVL.)
In both languages threads are an added after-thought and no, I disagree with you - multithreading is not an implementation detail. For example, why do you think classes in Java are immutable?
Also, I consider the standard library to be a part of the core language, because it is. Python doesn't have many concurrency primitives that are commonly used in Java, even really common ones, like AtomicReference or CountDownLatch. Heck, it doesn't even have volatile variables, let alone ForkJoinPool or other niceties. What's actually in the standard library? Well, the multiprocessing library is now baked in for doing "process-based threading", which really means stuff based on fork() that is unportable, because the language implementors gave up on threads a long time ago.
It doesn't stop at concurrency primitives though. 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.
Add to that libraries like NumPy/Scipy that are basically unportable, or 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, or the myriad other libraries in the ecosystem all written for CPython and expecting a GIL. Anybody that is fantasizing about Python having a usable implementation other than CPython is delusional.
> In both languages threads are an added after-thought
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.
MRI has native threads a GIL, but you can already release the GIL and run freely in native extensions.
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.)
> Python's standard library additions and syntactical choices were strongly influenced by Java in some cases: the logging package,[27] introduced in version 2.3,[28] the threading package for multithreaded applications,[29] the SAX parser, introduced in 2.0, and the decorator syntax that uses @,[30] added in version 2.4[31]
I think the new enums in python 3.4 are based on java enums(module for dynamic typing, for example I beleive comparing them to ints or adding them if they have int values will fail at run time as opposed to compile time) as opposed to enum as an alias for integers.
