From: Austin Ziegler <halostatue@...>
Date: 2006-06-06T00:37:52+09:00
Subject: Re: I love Ruby - But how bright is Ruby's Future?

On 6/5/06, ReggW <me@yourhome.com> wrote:
> Phil Tomson wrote:
>> Actually, you should never get complacent about a language's 'lasting
>> power'. Always be ready to learn a new one.
> I don't agree with this statement.

I'm not sure why you don't agree, because your example (Kylix &
C++Builder) very *much* agrees with what Phil said.

> You should look very hard at a language (just like the owner of this
> thread is doing), to make sure you are making the right choice.

If you're planning on making it your primary programming language, sure.
I don't get to spend a lot of time programming in Ruby with my current
job, but my Ruby has definitely informed and improved my C++ (and
congealed my hate of that language).

[...]

> Look at Kylix and C++Builder X, they fit the bill when they where
> released, but now people are scrambling to find a replacement (or a
> new job).

Actually, neither was a problem, nor are they really problems. Just
because a tool falls out of favour does not mean that the tool was bad
in the first place. Java *will* fall out of favour, just as COBOL has.
That's inevitable. The trick is to be an agile enough to recognise when
something *new* has to be done.

> 1. No native OS threads.

This is less a problem than you might imagine. However, it will be
addressed with YARV/Rite. (In fact, Ko1-san is possibly planning on
making it possible to have Ruby's green threads run on top of OS
threads. Last year's YARV presentation suggested that it might even be
possible in the future for a green thread to migrate across OS threads
for performance reasons.)

> 2. To get the fully benefit from Rails, your database has to have a
> specific naming convention. (Makes it impossible to migrate to RoR
> from something else).

This isn't a Ruby problem. It is, however, still possible to migrate.
You will have to do a little more work, but you *can* override the
defaults for ActiveRecord and once overridden, all of the rest of the
benefits still apply.

> 3. No generic database drivers built into Rails for databases other
> than the top 3 and open-source databases. (Makes it impossible to
> migrate to RoR if you use a different database)

This is more a matter of applicability; if most folks don't need it,
they won't create it. Maybe it would be worth talking to the vendor
about this.

> 4. Slow performance.

This is often claimed, but never conclusively proven in a way that is
generally applicable and generally applicable to the language. Yes, Ruby
has points where it is slow. But performance is not an absolute
measurement; it is a relative measurement. There are definite places to
get improvements from the *language*, and many of these will be
addressed by YARV (which I'll finally be able to play with!).

> 5. Kind of a hack job to get it to work with Apache. (But this could
> also be my lack of knowledge)

I can't answer this, but I suspect that it's a knowledge thing.

-austin
-- 
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca