From: ReggW Date: 2006-06-06T01:31:20+09:00 Subject: Re: I love Ruby - But how bright is Ruby's Future? Austin Ziegler wrote: >ReggW wrote: >> 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. > It wasn't the tool that failed, but the framework (and of course Borland had a lot to do with that). >> 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.) > This is a problem that I'm experincing now. I'm "trying" to convert an existing app that uses thread to Ruby. This brings up another issue that I have (and I suspect many other) is that I'm always seeing these new names being used. Like YARV/Rite but none of this is anywhere on the rubyonrails.org website. The website doesn't inform you of what is being worked on for the next release, actually, the website doesn't inform a person about much of anything that is currently going on with Ruby. >> 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. > Talk to what vendor? My database vendor? And asked them what?? This could be resolved with a out-of-the-box ODBC/JDBC driver as part of the different type of databases supported. >> 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!). > I wish I knew what this YARV is...it sounds like the magic bullet I've been looking for. I'll do some research on it later. Thanks -- Posted via http://www.ruby-forum.com/.