Perhaps there’s no point in arguing, but the analogy is valid :P

I would also very much enjoy seeing a more concrete discussion of why Ruby may or may not have FAIL. And global discussions of whether a language or technology is “good” itself is sort of a red herring. Ruby does have fail at some things, because like all technology, it’s got things it’s good at, and things it’s not good at.

Really a discussion about leaving a community, or whether a particular ecosystem meets your needs is always a subjective one. This is particularly why i find all these Ruby Shark-Jumping posts ridiculous.

Zed didn’t flame out of the community because of technology, he flamed out of the community because he either didn’t like people or didn’t want to deal with them. That’s a social problem, not a technology problem.

If the tech works for you that’s great. If it doesn’t, that’s not Ruby’s problem. That’s Ruby not fitting what you need it to. Or, even more likely, you losing interest in exploring ways to make Ruby fit into your workflow better, rather than some other technology. Then again, perhaps another technology would be a better (easier) fit. I don’t know, again, it’s subjective.

In the meantime, I don’t suppose you’d reconsider the initial part of your post where you call me a liar and and compare me to Joe Liberman supporting John McCain? Because you pretty much outright imply I’m lying about liking ruby to candy-coat an unpleasant point by association. This is a touchy subject, and I think it’ll all go better if we stay civil.

As someone who is actually worried about the potential fracture of the implementations (and who has had to deal with that in JS in my work on jQuery), I’m relatively pleased with the state of Ruby on that front.

The RubySpecs project has taken a very tenuous situation and created a crop of Ruby implementation that are almost completely compatible. It also provides a way to punish implementors that are building “forks” of Ruby, and so far no one has stepped up to receive that punishment (all known implementations are using RubySpecs as a measure of completeness).

I just don’t see the future of Ruby as one of “many divergent, mutually exclusive paths”. Where’s my mistake?

I don’t consider my application terribly specialized though. In my time since 2003 writing Ruby, I’ve been writing glue code between multiple libraries and interpreters as a matter of course. I did it for Lockheed (bindings to control software), Ma.gnolia.com (classifier gem, which I don’t maintain anymore), and powerset.com. You don’t see a lot this kind of code open sourced, but it’s out there and it’s real. Even the Merb project is working off a C binding. If the JRuby FFI can cope with your needs, that’s great. I quietly explored using it and found it insufficient earlier this year, and maybe I should revisit it.

(Aside, do you really want us to re-write a massive prolog app for the java prolog interpreter? Sir, I have to think you’re not serious about this or just a little uninformed about the lisp-like condition of prolog interpreters).

For JRuby, my concerns for my specific work (in order of priority) are:

1. The minimum startup size of a ruby interpreter in Java. Unless you’re willing to radically change your infrastructure to go threaded, it’s very expensive do do the traditional deployment and run many procs on one machine simultaneously. I could re-engineer, but it would sure be nice if I didn’t have to. And that’s the promise that other optimized ruby projects

2. The underlying engine is a massive, complex system with a huge soup of requirements. It’s a neat piece of software, but way overtasked for modern use. I think that it behooves Ruby to have its own interpreter, and I am not in the camp of people who think writing new, specialized VMs is a fool’s errand.

You say that Ruby’s growth and innovation are accelerating, but this is not the issue. Ruby’s *core* is stagnant. While other interpreted environments are skyrocketing towards nearly compiled-code performance with dynamic compilation and optimization, Ruby’s interpreter tech is stagnant and it’s difficult to make the case that there is a clear evolutionary path forward.

We’re at a fork in the Ruby Road. Many divergent, mutually exclusive paths stretch forward before us. Without a clear, dominant ruby implementation to migrate to the community fill fracture into numerous sub-ruby groups, each with code that they can’t quite share with the other group (could you write a deployment-quality version of merb that runs well on rubinious and jruby, right now?) I’ve seen this problem in the Lisp community and the consequences are… let’s say they’re not optimal.

It’s doubly frustrating because all around us there are amazing things being done with other interpreted languages. Working with Javascript lately has been incredibly rewarding. I want my Ruby skills to remain relevant!

However, your general theses are fairly flawed. While JRuby might not have worked for your very specialized application, your argument was about the future of Ruby in general. In general, Ruby applications are not linking a C runtime, Prolog, and Ruby.

But if they were, you could use JNI or JRuby’s FFI and a Java Prolog interpreter (a few are at http://kaminari.scitec.kobe-u.ac.jp/logic/jprolog.html).

Are your concerns about memory size and startup time or GC? My biggest complaint about your post was just that it seemed to be a muddled argument that ignore a number of good solutions and projects that are on the cutting edge of Ruby.

Rather than stagnating, Ruby’s growth and innovation are only accelerating. I was confused about your arguments to the contrary.

And I’m a little mad that people keep saying, “He dismisses JRuby out of hand.” I don’t dismiss JRuby nearly as blindly as you think. The reality is that I can’t use it in my day to day ruby work (and I have a lot of it), because I’m working in heterogenous environments trying to use Ruby for one of this original (and brilliant) applications, as a glue layer. A *lot* of ruby code functions in this way (historical necessity). Are we going to dismiss that out of hand as well?

Yes, JRuby may be the light and the hope for the Rails and Merb communities, and I think that’s awesome and I hope it’s true. But it’s not going to help me and a lot of other people working on integration work. I’ve already got a prolog interpreter, a complex C runtime and a ruby interpreter all in one process for a specific project, now you expect me to shoehorn in the JRE? Oh wait, I suppose I’m “doing it wrong” trying to use Ruby.

And the thing is, before I published I went and talked to a lot of very respectable, competent rubyists and even game them early proofs. I got a lot of tweets from very prominent rubyists saying, “You’ve said what I’ve been worrying about for some time now.” I don’t want to bash ruby, I want to shoot up a flare and say, “Guys, if we keep on this path we’re going to be the next perl6, and I don’t think anyone wants that.”

What does this even mean? Django isn’t event a language! If you really meant Python, I would be careful comparing Ruby to Python or even Perl for that matter. Ruby is great for writing web applications but the 1.8 interpreter is much slower than Python or Perl. For me real-life applications include churning through very large text file. Last time I did this with Ruby on a 2 GB file, I rewrote the script in Python before the Ruby version was even finished! I let the Ruby version run for over an hour before shooting it dead. The Python version took less than 10 minutes.

Also, I could be interpreting KirinDave’s post wrong, but I saw it more as an outcry in regards to the Ruby development process. Don’t get me wrong, I love Ruby but before Ruby I worked in Java and Python. With those languages the growth was guided by the community and was visible. Java has JSR’s and Python has PEP’s. What does Ruby have?