The Rails Myths
loudthinking.com
The Rails Myths
1–10 of 11 posts
Re: The Rails Myths
#2By coincidence, I was up until 2 last night getting a Passenger install to work. I'm deploying multiple apps to this new server I'm setting up and didn't want to install gems globally (Rails' version of DLL hell) and had all sorts of fun with freezing Rails and gems, and getting Capistrano to work.
And, yes, Passenger made this whole process easier than it was when I did this with Mongrels. It's still not simple and easy.
Re: The Rails Myths
#3By coincidence, I was up until 2 last night getting a Passenger install to work. I'm deploying multiple apps to this new server I'm setting up and didn't want to install gems globally (Rails' version of DLL hell) and had all sorts of fun with freezing Rails and gems, and getting Capistrano to work. And, yes, Passenger made this whole process easier than it was when I did this with Mongrels. It's still not simple and…
It's still not easy, you mean, when you try to override the default package manager.
Re: The Rails Myths
#4By coincidence, I was up until 2 last night getting a Passenger install to work. I'm deploying multiple apps to this new server I'm setting up and didn't want to install gems globally (Rails' version of DLL hell) and had all sorts of fun with freezing Rails and gems, and getting Capistrano to work. And, yes, Passenger made this whole process easier than it was when I did this with Mongrels. It's still not simple and…
It's still not easy, you mean, when you try to override the default package manager.
Yes, it is not easy to avoid the Ruby version of DLL hell.
Re: The Rails Myths
#5Earlier quoted context omitted.
It's still not easy, you mean, when you try to override the default package manager.
Yes, it is not easy to avoid the Ruby version of DLL hell.
I think it's a silly comparison you're trying to make. "DLL Hell" is "Hell" because there's a system-level depot for binaries that is hard to override. If you really need multiple global gem depots, just run multiple builds of the same Ruby.
The first thing every team I've worked on has ever done with Ruby (and Python and Tcl before that) is roll a project-specific Ruby build, so that nobody is working off the polluted system Ruby. It was even worse with Python, which for a couple years was a whole major version back from mainstream Python.
I'm not saying there isn't a real problem here; if you're hosting apps for 3 different teams, you do have to do a little dance to deploy seamlessly for all 3 of them with all their deps.
But most teams are never going to run into this problem, and I don't know of a really elegant solution for it.
Re: The Rails Myths
#6I'm an Ops guy who just happens to write a lot of code, rather than a coder who happens to handle Ops, and I can testify that Rails is not fun to manage, from an Ops perspective.
Setting up a tightly version-controlled, centralized deployment for a full Rails app stack is more difficult than doing the same with J2EE, but this is partially due to the immaturity of the platform -- Ruby, and Rails, just haven't been in the mainstream for anywhere near as long as Java has.
Re: The Rails Myths
#7Earlier quoted context omitted.
Yes, it is not easy to avoid the Ruby version of DLL hell.
I think it's a silly comparison you're trying to make. "DLL Hell" is "Hell" because there's a system-level depot for binaries that is hard to override. If you really need multiple global gem depots, just run multiple builds of the same Ruby. The first thing every team I've worked on has ever done with Ruby (and Python and Tcl before that) is roll a project-specific Ruby build, so that nobody is working off the pollut…
To my ears, you're describing "DLL hell", but saying that it isn't really DLL hell, because you can work around it, and because the problems are just as bad in some other languages.
Personally, I think Rails is pretty hard to deploy. There are just too many global inter-dependencies that need to be managed.
Re: The Rails Myths
#8I'm an Ops guy who just happens to write a lot of code, rather than a coder who happens to handle Ops, and I can testify that Rails is not fun to manage, from an Ops perspective. Setting up a tightly version-controlled, centralized deployment for a full Rails app stack is more difficult than doing the same with J2EE, but this is partially due to the immaturity of the platform -- Ruby, and Rails, just haven't been in…
[deleted]
Re: The Rails Myths
#9We build a small, versioned depot of ruby + rails and other gems. Running this with Apache/mod_fcgid works really well and is very stable.
Re: The Rails Myths
#10I'm an Ops guy who just happens to write a lot of code, rather than a coder who happens to handle Ops, and I can testify that Rails is not fun to manage, from an Ops perspective. Setting up a tightly version-controlled, centralized deployment for a full Rails app stack is more difficult than doing the same with J2EE, but this is partially due to the immaturity of the platform -- Ruby, and Rails, just haven't been in…
...And J2EE is incredibly painful already.