Actually lots of smart folks (Dave Thomas, Martin Fowler) have been Ruby fans for quite a while.
A lot of smart folks are/were CL and ST advocates as well. Lets reference Gregor Kiczales, for example.
Actually, there was: it's much easier to write DSL's in a dynamic language that supports meta-programming, like Lisp, Smalltalk, or Ruby, than Java. Why not Lisp or Smalltalk? Well, most folks find these languages hard to read and get started with.
And any advocate of their environment will tell you that folks didn't more handwaved CL or ST based on it "looking funny" rather than actually trying it. Syntax bigots, and baby out with the bathwater type people.
My point was that Ruby has had the power for Rails for quite some time, nothing special (save for Hansson just Doing It) enabled it over CL or ST. He could have easily picked any of them.
Good point; the best technology doesn't always win. Java wasn't revolutionary, but it had more hype.
What Java had was Sun smart enough to essentially give it away and rally the rest of the industry around its standards. You can call that hype, but for whatever reason IBM felt it in their best interest to replace the Smalltalk program that they had invested heavily in, no doubt hyped themselves, and had proven experience and deployments with, with an unproven Java program and EJB.
That's a VERY curious thing to do, don't you think? That change over was not cheap, but they felt it worth doing.
Still, open source tools like Apache, Linux, and Perl (strictly for scripting) have made some headway into the corporation, with major industry backing, at least intially. And if Ruby gets popular enough at the bottom end of the market, someone will pick it up.
The commerical webservers weren't "better enough" for most deployments thatn Apache was, most folks STILL use Apache 1.3.x, which has been developmentally dead for several years, and 2.0 doesn't have much force behind it, and certainly no corporate advocate selling it to industry.
Save for Linux and IBM/RedHat, very few OSS projects have a large company behind them, and notably, none of the languages do. Python, Perl, PHP, Ruby, etc. You have ActiveState selling tools AROUND Python and Perl, but I don't know that they're improving the internals of the languages so much. I have NO idea who is funding Wall and Perl 6.
Part of IBM's attraction to Java was the fact that Sun was behind it, and developing it hard. I don't know anyone who is working to get any of the other languages performing well on large N-Way SMP servers, for example. The others may be picking low hanging fruit from Suns and other JVM research, but there doesn't seem to be a major force behind them.
Python and Perl have both been around longer than Java, and while certainly very capable for web CGI, haven't made the leap to where Java is, and no one has picked them up to lift them. Both of them could have ridden the "Internet Boom" wave. Python's ZOPE barely made a ripple, though I'd argue that Perl certainly succeeded, but never really broke through to the Enterprise and back office off the web tier(yes I know large sites run Perl).
So, yea, someone COULD pick up Ruby, but I'm not going to hold my breath.
The world may not have been ready for dynamic languages 10 years ago. Among other things because they were too slow. But machines are faster now, and for many apps the bottleneck isn't the CPU.
Absolutely, but here's the deal. Dynamic languages WERE here 10 years ago, and they performed well even then. GC has gotten better over time, but Smalltalk was well proven 10 years ago, and Common Lisp has been "industrial strength" for quite some time. Most of the "problems" with Dynamic languages have been worked out out for quite some time. The biggest addition that Java has added to the pot is better JITs, better GC, and a lot more experience with multi-threading across CPUs (a rarer beast back in the day), but most of that started in the Self project, and that was 10 years ago.
But Java is a sitting duck. Some sort of dynamic language will replace it, eventually.
The problem with the dynamic languages is simply that -- they're dynamic. Their power and passion and benefit is their curse. All of that flexibility TENDS to become unmanageable in large projects with lots of people.
Many folks lament that lack of static type checking during builds that are not available within most dynamic languages.
Dylan worked out a nice balance between the two issues, but never caught on. Common Lisp CAN be made to work that way, but, of course, it hinders the dynamic nature of the development, and most of the time you type your code for performance.
Look at the classic concepts of scope within Java and C++, things like private and protected. These concepts keep coming back in languages, this ability to lock the interface down and completely hide (and more importantly, protect) the implementation.
For large projects, with assembly line "coders", it IS important to protect the programmer from himself. One of the key tenets in Java is to do that, keep it "safe". Dynamic language, by definition, are "unsafe". There are many ways to do odd things that will not crop up until runtime.
Corporations like "safe". Safe is predictable. Safe is schedulable. Safe makes planning easier, especially in the dynamic environment of software development.
AOP, for example, is welcomed in to the Java community, not with open arms, but with scrutiny, with distrust. Some folks love it, others loathe it specifically because of its dynamic nature. They want things more explicit in their code. They want the code to do what it says it's going to do. AOP tends to blur the edges of dynamic coding and static Java.
Note, I love dynamic languages. I am a Common Lisp "Fanboy", but I'm not the world. I am glad we're not using something as flexible as Common Lisp on my project with the team I have here, and I imagine my team is just like most every other team with it's combination of Stars and dim bulbs. The wild goose chases alone would be just be murder.
When you're alone, when you're working in a very small group of similar minded and talented people, dynamic languages can be very powerful. But to mis-quote "Men in Black": "Yes, Programmers are smart, but Projects are stupid, panicky animals and you know it."
Communication is the killer in large groups, and it's too easy to play "telephone", where what's said at one end gets corrupted and confused by the time it goes through several people, with a dynamic language than a more static one that enforces barriers along each step of the path.
So, dynamic languages will have their place, and they're wonderful tools, but until you change the people, I fear you're not going to be able to change the process to where a dynamic language really goes mainstream.