From: Austin Ziegler Date: 2006-06-06T01:45:35+09:00 Subject: Re: I love Ruby - But how bright is Ruby's Future? On 6/5/06, ReggW wrote: > 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). Um. Has the framework failed, or is it now just that the vendor support for the tool and framework gone away? >>> 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. Um. Why does your existing app use threads, and does the assumption that moved you to threads still apply, or may multiple processes with some form of IPC be better? I wouldn't simply try to do a functional conversion of an application from any language to Ruby. I'd take it as an opportunity to reimplement based on what I've learned about how the application is actually used. > 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. Nor would it be. Rubyonrails.org is about Rails, not Ruby. Look at ruby-lang.org and rubygarden.org and the mailing list history[1]. The Rails website will never be about Ruby in general. > 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. This is correct. This is because it's the Rails website, not the Ruby website. The Ruby website needs a bit more content up-to-date, but I hope that will change when the new visuals come on-line, too. If you REALLY want to know what's happening with Ruby's future, join ruby-core@ruby-lang.org and watch rcrchive.org. >>> 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. No, it can't. Why can't it? Because if people don't *need* such a driver, they're not going to *develop* such a driver. I'm sure that the Rails team would be happy to add other drivers (if there aren't plugin- hooks for use with RubyGems for such drivers, which is even more sensible), but it has to be developed first. That's why you talk to the database vendor and say "You should really look at this Rails thing." Maybe get *them* to develop the driver for you. >>> 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. There are no magic bullets. YARV is predicated on Ruby 1.9 and there are syntactical changes in Ruby 1.9 (which is the development bed for Ruby 2.0). -austin [1] You may *think* you're posting to a web forum. You're not. You're posting to a mailing list (ruby-talk@ruby-lang.org) over a web forum interface. You're dealing with something that has a much longer history than Rails. -- Austin Ziegler * halostatue@gmail.com * Alternate: austin@halostatue.ca