That's not nice all in my opinion.

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.