4 ms·
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
by flocial 15y ago
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.
- Volpe 15y ago> 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' ?
- gtani 15y agoI've heard of a few deployments where the dev environment is MRI/"C-ruby" and production is JRuby.
- nirvdrum 15y agoGiven 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.
- philwelch 15y agoHeroku 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.
- Volpe 15y agoOkay, 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?
- deleted 15y ago[deleted]
- regularfry 15y agoRsync.
- flocial 15y agoI 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.