That's not nice all in my opinion.

I don't want "choice" concerning what implementation of my language to use. Unless I have some strange, specialized need, I want one implementation that is guaranteed to work. I mean, the point of a garbage collected language is ... I don't have to worry about the garbage. If I have to make special study to find which implementation has " sane garbage collection", then this purpose been lost.

The various versions are forks and for forking to work, the winner needs to be picked really quickly to allow us to move on.

The thing about C++ is GCC is good enough almost everywhere and any other implementation is going to have to be as good as that.

There are good things about Ruby but dueling implementation breeding uncertainty is not one of them.

We definitely have different points of view then. I see single-implementation languages as things to fear. Software projects die, sometimes suddenly. The genius in charge might get hit by a bus, a particular implementation might violate the wrong company's patents, or the owner of an implementation might see an opportunity for profit. When you have options for language implementations, these risks are at least mitigated.

Unless I have some strange, specialized need, I want one implementation that is guaranteed to work.

I'd love guarantees of perfection too, but I've never seen one. I'm guessing that if I ever did see a guarantee of perfection, I wouldn't be able afford the software it was attached to. Software Engineering, like every other field of engineering, is about tradeoffs. Sometimes they're difficult tradeoffs, but it's your job as a professional to inform yourself and make the best decision you can.

I mean, the point of a garbage collected language is ... I don't have to worry about the garbage. If I have to make special study to find which implementation has " sane garbage collection", then this purpose been lost.

The point of garbage collection is that it allows you to focus on other things first, and then come back and look at your memory use. Even in a language running on a really advanced GC, like the Oracle JVM, you can't ignore your garbage. You need to close files when you're done with them or you will run out of file handles unnecessarily. You need to keep track of your heap use or your program will thrash and your GC will have problems. There's no silver bullet, but being informed about the details of your platform will help you.

The various versions are forks and for forking to work, the winner needs to be picked really quickly to allow us to move on.

Forks are based on common code. We're talking about separate implementations, with different teams and different goals. Nobody working on YARV cares whether ruby interacts well with java libraries. JRuby developers do care. Different teams, different focus. I don't think a winner is going to pop out, and I don't see why one is needed. I do think a better GC for non-JVM ruby would be really good, and somebody probably will make a compliant ruby implementation that has one, but that won't hurt anything. If it's an overall better implementation people will move to it, and YARV will probably go into the background.

The thing about C++ is GCC is good enough almost everywhere and any other implementation is going to have to be as good as that.

The thing about C++ is that it's a standard, not a piece of software. There are dozens of active implementations focusing on the embedded space, windows, solaris, and other platforms. No one implementation is the best for all purposes, and a professional chooses the correct tool for the job.

There are good things about Ruby but dueling implementation breeding uncertainty is not one of them.

Is anybody really feeling uncertain about ruby's future because it can run on the JVM as well as running in a less dependency-encumbered environment? I can see people being unhappy about the most common ruby implementation having a crap GC and really bad threading support, but having people working on their own ruby implementations is only going to improve the situation.

Well indeed, the point isn't some much single-implementation languages as language in which I, the naive user, do not have to choose between implementations.

>> Unless I have some strange, specialized need, I want one implementation that is guaranteed to work.

> I'd love guarantees of perfection too..

Hold up. I would hope my language doesn't imply 'perfection' but "least-common-denominator-works". I was too strong with "guaranteed" but works in the "fairly normal" use-cases is good.

Even in a language running on a really advanced GC, like the Oracle JVM, you can't ignore your garbage.

Wait, who's "you" here. I the poster stand by the claim that I, the naive developer producing something really simple like a GUI to, say, move one file really shouldn't worry about GC. I the advanced developer producing something like an object-database indeed have to worry about GC.

- I would note with a Ruby instance copying one very large file from one to place another, you do have to worry about the GC, since MRI never gives memory back to the system, EVER. One of the founders of Twitters personally described to me discovering this to his horror, WELL into Twitter's period of trouble. Not at the start... and this was someone dealt DAILY with the system. DAILY...

Forks are based on common code. We're talking about separate implementations, with different teams and different goals.

I call BS here. What common code exists between Rubinius, YARV and company????? Seriously, I've been slackly following Rubinius for a while and unless they've added something recently, they have no common code. Rubinious has been trying to create a common test framework but that doesn't imply any common code. My impression is Rubinious doesn't even use the YACC code from YARV/MRI. Prove me wrong, it's happened before...

In a lot of ways, Rubinious' common test interface highlights the dead end of Test Driven Development as well as it's negative impact on Ruby. Software tests can't in themselves prove SHT, I mean they can't prove the equivalence of anything.

The thing about C++ is that it's a standard, not a piece of software.*

Well, that is indeed a good point. But the point highlights the problems of Ruby, which has nothing like a common standard.