The problem with Rails is not the pace of change so much as the wild changes of direction it takes, sometimes introducing serious performance degradations into official releases. Sometimes it's hard to see a guiding core philosophy other than the fact they want to be on the shiny edge. It's nice that they aren't stuck with bad design decisions forever but when you go in for an upgrade and you depend on some unpopular plugins, you can bet on pain and even performance problems.
A major issue with some parts of the community is that some programmers think that being rubyists automatically makes them elegant programmers even if they don't have a clue about proper algorithms and that's probably why others call them "hipsters". The general disregard for improving performance, inherited from Ruby, is also something endemic from a while back. Sure programmer time is important but how many successful companies have started with Rails only to end up with a patchwork of Java, Scala, C++, etc. after lots of downtime and growing pains.
Getting your app into production is also another pain point with the all the dirty tricks you need to master, not to mention an array of lackluster choices be it nginx, passenger, unicorn, rvm, REE, bundler, etc.
So with that background, I think the author's gripes are understandable but it really doesn't touch on the undercurrent of discontent surrounding the current ecosystem.
> how many successful companies have started with Rails only to end up with a patchwork of Java, Scala, C++, etc. after lots of downtime and growing pains.
So how many? I've hardly heard of this as the 'norm' for growing companies on rails... ? This sounds like 'Does Rails Scale' FUD.
Getting your app into production is not a pain point at all, services like heroku, or engineyard have made this as simple as 'git push'. Which nirvana of release management are you coming from where this is a 'pain point' ?
Heroku exists because Ruby deployment is a major pain point and developers are willing to embrace serious architectural limitations and high rates in exchange for willing this problem away. I'm not down on Heroku at all, I think they're brilliant, but "use Heroku" isn't a universally viable technical solution to this problem.
Heroku exists because Ruby deployment
is a major pain point
No dude, Heroku exists because dealing with hardware, OS configuration and updates and maintaining a scalable infrastructure (that can be upgraded to how many servers you want, or downgraded) with a sane deployment workflow is a major pain in the ass, no matter the dev tools you're using.
In fact, I found the deployment story of Rails (with the help of Rvm, Rake, Bundler, Capistrano and Passenger) to be the best one yet and no other environment can really match it (although you get pretty close with Python, Django, VirtualEnv, Pip, Fabric and mod_wsgi for example).
And I'm not using something like Heroku btw, as I consider it to be seriously overpriced - I'm maintaining my own Linux servers on top of EC2 (which still involves pain, that I can handle nonetheless, but then again I also have sysadmin skills). Deployment for me is literally just "git push && cap deploy".
Okay, pre-heroku, Capistrano, which again was a huge simplification on other deployment processes. How is rails more of a pain point than anything else? Deployment is always going to be a task that is required. Rails has for a long time had pretty good solutions to this.
I'm objecting to the parent stating that deployment is a serious pain point for rails.
I would like to know what the 'simple' deployment stack people are comparing the Rails stack too?
PHP.
I used rails exclusively for webdev the last 6-7 years and I just now worked on a PHP project. Deployment of PHP is the same as deployment of static HTML. How is that not simpler than what we got in rails. For rails you need to understand version control, webservers and scripting. For PHP you need to understand copy.
For a serious project I think rails is great but you can't deny it involves lots of abstractions which sometimes break down and then necessitate expert knowledge that most people don't have.
Deployment of PHP is the same as deployment
of static HTML
Until somebody other than you does a database schema change or data migration, and forgets to tell you about it. Or until somebody adds a new PHP dependency (for resizing images or other shit like that) and forgets to tell the rest of the team.
For rails you need to understand version control,
webservers and scripting
No shit - those things are required in PHP too, unless you're building a contact form.
you can't deny it involves lots of abstractions
which sometimes break down and then necessitate
expert knowledge
Those abstractions save you from dealing with boilerplate or with repetitive tasks that you can easily forget about. They are based on sane practices used by experts. And those same abstractions are also present in mature PHP frameworks like Symfony and not because the developers were bored to death and just wanted to complicate your life.
Rails is not for contact forms. You are better off using PHP for that - but I saw contact forms evolve into big piles of unmaintainable crap and developers doing that because they thought a mature framework was too complicated and haven't evolved since then - shouldn't have a place in this industry.
I truly understand the points you give and I like the fact that rails has a proper process for all of this.
Fact is though that 90% of projects that I didn't start myself involve FTPing stuff to a server were all the developers muck around writing over each others files.
Horrible yes. State of the art in most web consultancies also yes.
Passenger allows one to basically work this way with ruby too and it is sorely needed because there are 'developers' out there that seemingly haven't worked with Sourcecontrol in their entire career. If you need to give them access to some templates it is nice if you don't have to bring them up to speed on git first.
I wouldn't hire those people but I was forced to work with some.
My point: Allowing a less robust but easier deployment method is a pareto improvement because I can now choose. It is also a path towards sane practices used by experts when you start with a big pile of unmaintainable crap.
I get what you're saying - and I think simple scripts uploaded by FTP are good in many contexts.
However, Ruby on Rails was never good for shared hosting. It was never designed or intended for this purpose. The deployment solutions available are not doing so good in a shared hosting environment. Or at least, not as good as PHP (nothing is as good as PHP in shared hosting).
The deployment story got a lot better when Passenger came along in 2008, which is a self-healing and easy to configure server, capable of functioning with Nginx or Apache in front. You wouldn't believe the shit you had to pull before that for reliable servers.
Personally, I hate Heroku because their prices are for the moment too high and I could partly replicate their environment on my own, using already available tools. But such hosting services will become the norm as they are so kick-ass and convenient; for instance I just received an invitation for Gondor, a Heroku-like service for Python and Django.
I think Java deployment is pretty straightforward and php is dead simple. I guess it depends on how much traffic your site gets but the larger your Rails site gets the more moving parts you end up with (at a lot less traffic than say a Java stack), higher server specs, reliance on memcache, some proxy, etc. just for a standard dynamic website. Sure you can wrap that deployment dance into a Capistrano recipe but it's not inherently simple.
But the main point is that since Rails/Ruby requires a lot more resources (cpu, ram, etc.) and wraps a lot up into a black box (auto-generated queries that might have a deadly join or two), when you deploy it's more "thrilling" for want of a better word.
I'm not saying Rails sucks completely, but the programmer productivity thing is oversold because in a small shop, the dev guys are usually babysitting servers too. This and some whimsical api changes can dampen your enthusiasm a bit. I just wanted to emphasize that some Rails enthusiasts are zealously in a state of denial of Rails/Ruby short-comings and putting a Rails app in production/deployment can be a bit challenging. Like others have said, the number of startups focused on making deployment and scaling of Rails apps "easy" kind of says something.
Given how different the two of those can handle things, particularly with dependencies, that strikes me as a bad idea. I'm not even sure I'd trust it to CI. This isn't academic either. I'm contemplating moving to JRuby. I really think I'd be more comfortable with my local dev environment matching my deployment environment.
A major issue with some parts of the community is that some programmers think that being rubyists automatically makes them elegant programmers even if they don't have a clue about proper algorithms and that's probably why others call them "hipsters". The general disregard for improving performance, inherited from Ruby, is also something endemic from a while back. Sure programmer time is important but how many successful companies have started with Rails only to end up with a patchwork of Java, Scala, C++, etc. after lots of downtime and growing pains.
Getting your app into production is also another pain point with the all the dirty tricks you need to master, not to mention an array of lackluster choices be it nginx, passenger, unicorn, rvm, REE, bundler, etc.
So with that background, I think the author's gripes are understandable but it really doesn't touch on the undercurrent of discontent surrounding the current ecosystem.