The one thing that has always put me off of Ruby on Rails is the upgrade story. It looks like a massive pain to keep updated, and an even bigger pain to bring up to date if you don't stay on the update treadmill.
I initially built my saas product in Rails. It was great, for a while.
Updating was a source of anxiety that led to rewriting the service in another language. It was a real pain... gem X would depend on Y. Y would need version Z of Ruby and Rails version W. You try to update X by updating Y and everything breaks apart. Same story for 15 other gems you depend on. You end up in a web of crazy dependencies. This is even worse if you use a heavy Rails engine (like rails admin, etc).
You eventually get backed into a corner and you "live with it" like the author of the post described, until you rewrite it.
The "Learning on the job" section brought back some memories of my experiences solo-developing a rails app. I made some of the same mistakes, although I think I mostly made the mistake of avoiding learning. I knew I should be writing tests with minitest or rspec, but never made time to learn it (instead I rolled my own request test framework!) And I stuck with subversion because I didn't fancy learning this newfangled git thing. When it finally came to hiring a second developer they had to teach me these things, and they thought I was an idiot :-(
3 comments
[ 3.3 ms ] story [ 14.2 ms ] threadUpdating was a source of anxiety that led to rewriting the service in another language. It was a real pain... gem X would depend on Y. Y would need version Z of Ruby and Rails version W. You try to update X by updating Y and everything breaks apart. Same story for 15 other gems you depend on. You end up in a web of crazy dependencies. This is even worse if you use a heavy Rails engine (like rails admin, etc).
You eventually get backed into a corner and you "live with it" like the author of the post described, until you rewrite it.