Slashdot Mirror

Where the hell are you getting your numbers? The chart shows that Ruby 1.9.1 is the fastest overall. I think somehow you mixed up the two columns.

I was one of the few who saw MagLev run against MRI before RailsConf, and the author of the shootout you're referencing. Ruby 1.9 is faster than 1.8. JRuby is faster than 1.8. MagLev is not only faster than 1.8, it blows 1.8 out of the water. Just to give you an example, in a few tests, Ruby 1.8 takes about 20 seconds to execute them, while MagLev takes about a second. The new shootout will be published soon and it'll include MagLev. By doing this, we'll have a fair comparison on multiple operating systems. I'll also expand the number of tests. These will still be synthetic benchmarks, but at least they'll give us a general idea of how well a given virtual machine's performance is.

Independent results will be coming soon, as outlined here.

You have a lot of things wrong about .NET.

Name them, because you've not managed it so far.

C++ is not a subset.

Didn't say it WAS, said it USED TO BE. That was long ago, I agree... and I said I thought it was no longer that way.

The CLR is fully capable of working with dynamic languages. There are quite a few that are already out and work fine. The DLR doesn't add anything new to the underlying runtime to better support dynamic languages. What the DLR strives to provide is a consistent pluggable API for hosting dynamic languages.

I didn't say it wasn't. I said the DLR helps make it more practical. Witness the folding of the already advanced Ruby.net, because he realized that in the end it will turn out better to go the DLR path and thus bow to IronRuby.

The power is in the libraries, but the libraries are consumable by any CLI-compatible language, or any native language hosting the runtime.

And I didn't say they were not consumable. I said that while they could be accessed, the libraries are built with C# in mind and not philosophically tailored in API to other languages.

That I think, is the biggest flaw of the whole concept that people will in fact use .Net for other languages (other than C+ which has a similar enough convention to it that people would adapt).

If you spend all your time consuming libraries in a different language, eventually you are going to just say "screw it" and use C#. How many new Eiffel users are there really because of Eiffel#? Or did it simply allow the life to be sucked out of that community by helping everyone learn to be a good C# developer?

The .NET runtime, from day one, was designed to be a very generic system.

Yes, I know, it couldn't help being so having been such a close copy of Java.

The one mistake was that generics was not in v1.0

Yes sorry the Java folks couldn't finish that in time for you. At least you went on a different path, though I personally think both paths were correct for the entities that took them (Ironically Java needed to choose the path they did exactly because of the same backwards compatibility issues being discussed here).

I too have been around from the beginning of both systems, I know all about what was added when.

The problem is the stock (1.8.x) ruby interpreter. As the language matures, better and better implementations of the interpreters are cropping up, and it seems that ruby 2.0 will easily catch up with python in terms of performance. There's nothing wrong with the language - blaming the language for the failure of the interpreter is tantamount to blaming C for the difference between the output of intel compilers vs. gcc.