No to Rails and Rails Apps.

I keep looking and browsing around and wondering? Where is the answer as to why I had so much trouble with Rails stuff? No luck. Nothing on the internet. And I’m pretty good at tracking down stuff. Especially with as many days as I’ve spent on this. No, the answer lies in the fact that as many people as there are out there using Rails, it isn’t really that big of a number. But what’s more, the problems I had most lay in standards, rather, the lack of standards.
The problem is simple, but the solution is not. Rails is new. Young. Relatively, anyway. Other solutions like ones built on Perl or PHP or Java have been stewing longer. Things are more settled. Especially dependencies and paths. Linux and Unix varieties have all come to a few standards of installation and tradition on who puts what where.
The same is true with Perl, PHP, Python, etc… Ruby itself is a no brainer, but with Rails, there is so much more stuff that can be broken. And the Ruby Gems collections? That’s what makes it bad. As cool as it is supposed to be, it isn’t. There is no floodgate, no valve, no control over when Gem A is released because Gems B and C and D all rely on it, but Gem E doesn’t care though it relies on Gem B,….
You get the picture. Any software stack can become this way, but these days it’s not good. Especially when the idea is to make things easier. Rails will never get truly huge until Gems is controlled by a group with standards requiring all apps to behave well with future/current releases.This is where PHP has an advantage. Its library of functions are distributed with the language. Major apps are out there and are compelled to be current. The whole thing is designed to avoid breaking apps.
Rails and many Gem based apps are not built this way. They’re built expressly to allow people coming from a GUI desktop app building background to apply MVC ideas to web apps. But it isn’t ready for primetime.
Now I can go out and build a Ruby based app. Just learn Ruby. I can do the same with PHP or Perl or Python, but their existing frameworks are a lot less troublesome to troubleshoot and get going. Perhaps there is more *NIX thinking in their design. That would certainly explain why they all bear a much greater resemblence to C..