Rails Has Turned into Java

In the year 2013 it is difficult to remember why Rails was such an explosive breath of fresh air, back when it burst onto the mainstage in 2004/2005. The essay that I think best captured the switch in popularity, from Java (and EJBs and Struts, etc) to Rails, was "The departure of the hyper-enthusiasts" by Bruce Eckel, written in December of 2005. He wrote:<p>"One of the basic tenets of the Python language has been that code should be simple and clear to express and to read, and Ruby has followed this idea, although not as far as Python has because of the inherited Perlisms. But for someone who has invested Herculean effort to use EJBs just to baby-sit a database, Rails must seem like the essence of simplicity. The understandable reaction for such a person is that everything they did in Java was a waste of time, and that Ruby is the one true path."<p><a href="http://www.artima.com/weblogs/viewpost.jsp?thread=141312" rel="nofollow">http://www.artima.com/weblogs/viewpost.jsp?thread=141312</a>

No, Rails hasn't turned into Java. Rails has matured into a complex ecosystem. Java has also matured into a complex ecosystem.<p>Frameworks upon frameworks is a recipe for complexity, potential performance problems, bottlenecks, and environmental/context-specific issues regardless of the language that you're using.<p>Will there ever be a language or simple framework that is popular, solves all problems, and doesn't get more complex as its ecosystem matures? I won't bet on it, but if you figure it out, someone will still eventually compare you to a no-longer-hipster-cool framework as an insult.

I don't get the Java hate. The stuff in Java is not there just to make your life miserable, it's a result of thousands of people spending millions of hours on complex problems finding that certain methods work well when your source code base becomes too large for simplistic methods.<p>The fact is: Java works, and it works well. Ruby/Rails is getting there, as we see from larger and larger code bases being build on Ruby/Rail and needing more and more of the hated 'Java' features - because they work.<p>Any language can be used for a small project and work very well - precious few can still continue to work well at scale.<p>I've found a lot of the HN crowd to be biased in this area. I believe that comes from most of HN working in startups which means less legacy code, smaller code bases, and more focused products with less management bureaucracy and changes. A sizable part of HN is also younger and hasn't yet worked in an environment of sufficient scale to require Java's(c++, advanced RoR, etc) features.<p>I could be way off here - but if you're knocking this kind of complexity and haven't worked on a massive project - it might simply be your frame of reference and you should stop knocking it.

The pushback against Ruby/Rails has been building for a long time. There's always been jokes about Ruby being slow:<p><a href="http://harmful.cat-v.org/software/ruby/" rel="nofollow">http://harmful.cat-v.org/software/ruby/</a><p>But there was a stretch from around 2005 to maybe 2008 where Rails seemed to defy criticism. It grew and grew, despite the criticism. I tried it for a project in 2006 and I became a fan. The easy use of 3rd party code, via gems, was much easier than anything I had known in Java or PHP.<p>I do not know a way to say when some of the criticism began to stick, but clearly things have changed. I have my own personal experience: once a fan of Ruby and now a fan of Clojure. And others have moved on -- there was recently the conversation about multi-threaded Ruby apps, and it seemed to me all the smart people agreed that jRuby is the future of Ruby: <a href="http://tonyarcieri.com/2012-the-year-rubyists-learned-to-stop-worrying-and-love-the-threads" rel="nofollow">http://tonyarcieri.com/2012-the-year-rubyists-learned-to-sto...</a><p>If I had to pick one moment when some of the criticism against Rails began to take hold, even among those who had once favored Rails, it was Zed Shaw's insane rant:<p><a href="http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto" rel="nofollow">http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto</a><p>Even though the tone is insane, he made some points that stuck in people's heads, including mine. This was important to note:<p>"I believe, if I could point at one thing it’s the following statement on 2007-01-20 to me by David H. creator of Rails:<p>(15:11:12) DHH: before fastthread we had ~400 restarts/day<p>(15:11:22) DHH: now we have perhaps 10<p>(15:11:29) Zed S.: oh nice<p>(15:11:33) Zed S.: and that's still fastcgi right?<p>Notice how it took me a few seconds to reply. This one single statement basically means that we all got duped. The main Rails application that DHH created required restarting ~400 times/day. That’s a production application that can’t stay up for more than 4 minutes on average."<p>And even now, in 2013, when I have to set up a new server with Rails, even with Nginx and Unicorn and all the other systems to help me, I find Rails annoying to set up, especially compared to the simplicity of PHP running on Apache or a Clojure app bundled up with something like "lein uberjar".

This is bullshit. I'm no fan boy but you can't blame yourself when you've cornered yourself in an complex case of interdependencies. BREAKING NEWS: OVER-ENGINEERED PIECE OF SOFTWARE IS REVEALED TO BE OVER-ENGINEERED.<p>I don't use Refinery, Devise, OmniAuth, Unicorn, Rack Rewrite, Fog, AMQP, or Heroku.<p>I use Passenger with Apache or Nginx, self-host, and write my own core functionality like authentication.<p>Rails is still great at having an idea and throwing together a proof of concept in one day; running "rails s" still works out of the box. It still allows you to defer the hard choices, until you actually have to make them. If you've cornered yourself by making your stack too complex too early, that's your own damn fault—in Java you have to make those architecture choices day 1.<p>Dynamic typing: if you treat Rails like Java, it acts like Java.

&#62; Sure, Rails itself is straightforward, but the frameworks you slap on top of it can quickly become burdensome abstractions: RefineryCMS, Devise, Omniauth, Carrierwave, Unicorn, Rack Rewrite, Fog, New Relic, Foreman, AMQP, and Honeybadger, not to mention the extra magic that Heroku gems throw into the mix (backups and other fun).<p>You don't need to use any of these. I once tried to use Devise for a project. I fiddled with it in an attempt to make it work exactly the way I wanted, but eventually I gave up and just rolled my own authentication. It's not hard at all to do in Rails, and you end up with much simpler code. I also tried New Relic, but I didn't see much point to it (maybe it's more useful for apps with a ton of traffic) and they sent me spam until I asked them to stop several times.

There's not a lot of content in this article frankly. I also suspect the author has either never been exposed to an 'enterprise' J2EE or Spring app, or has simply forgotten what a labyrinthine nightmare those could become. Rails is more complex today, but it is still significantly easier than traditional Java frameworks.

Flame-bait title if I've ever seen one.<p>Let's see an actual comparison with some numbers:<p>* Lines of code, and number of tasks necessary to get a development environment set up.<p>* Memory used with one client accessing the system, and with, say, 10 clients accessing it.<p>* Some performance benchmarks.<p>I keep my ear to the ground, and have used enough languages in my time that jumping to a new one isn't that big a deal, but I'm pretty happy with Rails and use it by default these days. It's a great way of getting something up and running quickly, while maintaining some order and sense of purpose to the code. It's what I'd use unless there are very clear reasons not to, such as huge scale requirements from the get-go, heavy involvement with web sockets or something like that where thinking a bit before coding is in order.

Particularly for small startups and self-funded projects, the most important factor in technology choice is almost always "How long does it take me to translate my idea into a working product?".<p>For me, I haven't yet found anything that matches the ability of Rails to quickly go from just an idea into something that you can start pitching to customers.<p>While Rails and the entire community is dizzyingly large, with rapid innovation, new libraries, and a new set of best practices seemingly every few months, this ability to quickly create stuff differentiates it from Java completely.

It's the age old set of trade-offs between buy and build.<p>Build it all yourself and it takes forever, but you understand it all.<p>Buy it from somebody else, and you get it quickly, but you're at their mercy for efficient understandable code.<p>No language or framework is immune. Enjoy your java.

He's trading most of the simplicity for rich pre-rolled features.<p>Building your own authorization/authentication and integrating with OAuth is pretty trivial, maybe a few hours if all you need is simply logging people in. Same with a CRUD CMS that'd replace refinery -- you're collecting complexity for a more rich feature set out of the box.<p>Rack Rewrite isn't really that complex, though Carrierwave+Fog is a complexity layer, if Fog is anything like S3 you could just be posting directly to a REST api(adding complexity in client-side JS -- my favorite kind of complexity.)<p>Unicorn is slightly more complicated to manage than Passenger, but, apparently you needed to serve fast clients and work on disk a lot? Well, can't be mad about what it buys you.<p>Honeybadger, Foreman, and New Relic are pretty much DevOps burdens, you'd probably have some form or fashion of this complexity in any web-based app, ever. AMQP is a standard, most people would need a library to interact with it -- this is sort've akin to complaining that you need a library/gem for JSON.<p>I wasn't even sure you needed heroku as a project dependency -- I though you just needed it locally because it acted like a CLI to their service.<p>Also, Sinatra is it's own framework, having nothing to do with Rails. And it certainly wouldn't trade out a lot of the dependency complexity you're dealing with.<p>Really, you traded simplicity for rich features out of the box. Hopefully you took the time to figure out if you actually <i>need</i> those features before integrating them with your app. Also, Refinery's Engine architecture is kind've hair brained.<p>(P.S. on chrome 24.0.1312.57 and Mountain Lion the dynamic length comment box on this blog is totally fucked.)

"... Java, have you learned to easy yet?"<p>No, it hasn't. That's why we're using Rails.<p>And to be honest, it ain't that bad.

Actually what's happening is that Rails is turning into MS Access. Access is a product that famously makes 80% of what you want to do incredibly easy, and the last 20% impossible. The Rails ecosystem is growing so that you can, essentially, deploy your own MS Access, with exactly the same trade-offs.

Sorry, but this article is bullshit.<p>First of all, it's a classic appeal to emotion; it uses hyperbole that is propped up with emotions ("You’ll find yourself staring at incomprehensible mega-frameworks maintained by developers who are unapologetic about how little they care for writing documentation", etc) and not by concrete facts. It cleverly it uses two fictitious quotes to imply it represents real people's complaints, when it's in fact the author himself making up the supposed complaints.<p>It also works up a strawman argument: That you can criticize Rails on the basis of a collection of frameworks that the OP apparently thinks are required to good apps. The fallacy here is that those frameworks are not needed, and their problems are not Rails' fault. Perhaps there is subculture of engine-loving Rails people out there that promote such frameworks, but I would not listen to them any more than I would listen to PHP devs.<p>Rails is like any other tool: What you get out of it depends on how you use it. Judicious use of gems, libs, frameworks, databases etc. is just as important as managing your own application complexity. Sorry, but complexity is bad whatever language or framework or whatever you use. If Rails is an easy target it's probably because the apparent ease of implementation makes it tempting to grow your app.<p>Here's a suggestion, a constructive suggestion: Try not to stuff you app with everything you can possibly think of. Login and user accounts? Belongs in a separate app. Document storage? Separate app. Image upload and scaling? Separate app. Email and SMS notifications? Separate app. Integration with external systems such that you feed data to, or from? Separate app. Computing scores or ranks or other statistics based on data? Separate app. And so on.<p>Use a service-oriented architecture for everything, and you will reduce the complexity of each component to a bare mimimum. For example, we use Checkpoint [1] to integrate logins (FB, Twitter, Google) through a single system, so that our apps don't need to deal with API keys or OAuth or anything; performing login in an app using Checkpoint is literally a single line of code (a redirect). Instead of using a database, most data fits into Grove [2], a structured, hierarchical, indexed data store on top of a relational database. Instead of reinventing rating and voting systems for every app, we use Kudu [3], and instead of reinventing flagging of spam or illegal content for every app, we use Snitch [4] -- just to mention a few trivial examples. Our stable of mini-apps has much more, a small ecosystem of reusable, composable tools.<p>By using HTTP as interface glue, we put an artificial limit on the ways that components can entangle themselves; for example, since the API deals entirely with basic JSON objects like arrays, strings and hashes, there are no surprises when you try to access the result of a call, since it will never re-enter its source (unlike, say, ActiveRecord associatons).<p>[1] <a href="https://github.com/bengler/checkpoint" rel="nofollow">https://github.com/bengler/checkpoint</a><p>[2] <a href="https://github.com/bengler/grove" rel="nofollow">https://github.com/bengler/grove</a><p>[3] <a href="https://github.com/bengler/kudu" rel="nofollow">https://github.com/bengler/kudu</a><p>[4] <a href="https://github.com/bengler/snitch" rel="nofollow">https://github.com/bengler/snitch</a>

I have to agree. I used to love rails in the beginning. I kept the source code to both Ruby 1.8.x and Rails (and Merb) easily available for browsing and it was all "understandable" at some level.<p>Maybe it is just laziness but in the last few years I have used almost exclusively much simpler libraries/frameworks like Compojure/Noir and Sinara - and I have lost interest in seriously reading the source to these libraries.<p>It seems better to have to write a little more code, but layer on top of much small libraries/frameworks.

You know what has become the "Best Java" for me?<p>Lua.<p>With the LuaVM, you really can fulfill the absolute promise of 'write codebase once, run anywhere', where "anywhere = wherever you've got your LIBS+LuaVM host code running", of course.<p>You can do it in a compact, highly performant manner. One host binary for each supported platform, much work at the vendor layer to adopt to a common Lua dictionary/table, and the rest is .. as they say .. fat city. All nice app case logic in a comfortable, friendly language.<p>Java long ago become an unweildy beast replete with inane dependencies and insensitive amounts of hassle to get things in and out, whereas with the Lua stack, it seems, one need only know how to do things at least with a C stack, first, to gain immense benefit.<p>I daily dream, in my idle moments, of a complete OS based on a selected set of normal/plain-ol' /usr/lib C-libraries, but booting directly to Lua, for GUI and all higher-layer goodness. Such fancies are already tickled in places like LOAD81 and MOAI, and so on, and I think sort of prove the point, a little, that the VM is no longer something a vendor controls, but rather .. the developer.

As someone who is just now learning Rails, I'm loving it. Is this an actual issue that should push me away from the technology? What other technologies are there that streamline the development process as much as rails?

I think Rails is following the footprints of the Wordpress eco-system. The once 'blogging-only' platform has now matured into a complex, component based, 'also-a-do-it-yourself-CMS' with so much code that just makes it fragile.<p>I'd love to see anyone write something custom based out of Wordpress and not have it automatically break in the next few updates. I believe this is the same case for Rails too. One day you would update your gems only to find out that something on your site (devise? Carrierwave??) would be broken. I guess, the best approach would be to make it modular - You know, write some custom classes and inherit them when you need them, instead of depending what the framework provides you 'out-of-the-box', of course not to the point of making the framework itself redundant.

To answer the question...Yes, Java has changed for the better. Give it a go...you'll be impressed.

"Rails isn't the easy framework it once was..."<p>I disagree. It's just as easy to set up a simple web app in Rails now as it was then. Rails may have grown in complexity, but it didn't add complexity to the easy thing.<p>"Sure, Rails itself is straightforward, but the frameworks you slap on top of it can quickly become burdensome abstractions"<p>I agree. However, I think it's so much easier to avoid these burdensome abstractions if you choose than it was in Spring when it first hit the scene. If you wanted to do something simple, I think it was far easier to write lower level servlet and jdbc code than to get spring mvc, hibernate, and some sort of build too (probably maven) all working together properly.<p>There were some good efforts. There seemed to be some enthusiasm about Roo, though I didn't find the code generated by Roo anywhere near as easy to work with as Rails code. I thought Play looked promising, though it wasn't enough to get me back to Java once I'd built some momentum with Rails.<p>A few people have commented that Spring 3 is excellent. It may very well be, and maybe I'll take a look some time, but to say I'm once bitten twice shy is to greatly undercount the number of times I was bitten.

I still remeber reading some blog post comparing the stack trace of a spring/tomcat web app and a rails web app. Blah blah the rails web app stack was much nicer to read. Well, in 2012, the rails stack trace has become the tomcat's stack trace. It seems that if you really need to implement alot of abstractions on a webapp for generic pipe/filter, interception, routing, param parsing, session managemnt and such, you really do need some layers in your app!<p>And I think it's funny that some of the Java-ey concepts that spring made so popular like IoC are beginning to appear in frameworks such as angular.js - this is not a critique, I think IoC is really clever.<p>As for JSF, I actually like JSF2. It's really not everyone's cup of tea, but it's quite good for those boring LOB apps. Oh and it's view-first! I don't know why there aren't more view-first frameworks. The other ones I know of are Lift, WPF (kinda, never really used intensively), angular.js (has a view-first feel to it).<p>Anyway, I still like rails, I just think they were a bit premature in judging the java camp...

Couldn't be more timely for me. I've been working on documenting the Discourse installation. For someone who doesn't work in Ruby every day, even as a long time Linux user, it is daunting.<p>Once an application, no matter the language, has a significant number of external dependencies deploying it becomes a challenge.

Post title seems like it should be, "Refinery is a messy CMS".<p>Seems like a good portion of these comments are comparing simple code written in (other-framework/language) with a big messy CMS written as an add-on for Rails. Hardly apples-to-apples comparisons, and only tangentially about Rails to begin with.

Nobody wins by just using programming language Y or framework X. Product, features, design, execution etc is what make you wins. Facebook won in social-networking using php, some other social networks were build in Java and failed. Amazon won using Perl. Instagram used python/django and got acquired for a billion. Yammer used ruby/ rails and was acquired for 1.2 billion.<p>In reality most companies are polyglot using different languages, tools and frameworks for different features in their stack.<p>I am personally tied of unnecessary rants. There is no perfect programming language or framework.<p>Abandon the notion that there's a "right framework," and just choose one and get hacking.

Ok, I get the complaint, and I understand and sympathize with the author. But just doing a simple search for "spring 3 hello world" was enough to remind me to stay away.

You're doing it wrong! Do not slap frameworks and complexity on top of Rails. Rails' strength has been unchanged from day 1 - "favoring convention over configuration".<p>Rails is for building web apps. 99% of the world's web apps will work fine with Rails, an RDMBS, a web server. That's about all you need. Anything else is probably just developers wanting to play with the latest toys.<p>So yes, if you try to avoid Rails' conventions, you will have trouble. But it's not Rails' fault.

Let me try another way. Some Rails apps that are too unwieldy are barely even Rails apps. They just happen to have Rails at some layer of the tech stack, but also have many other non-Rails components such that saying "Rails" has become too complex is disingenuous.

hope that means I have job options for another decade

Cheapshot: Rails HAS turned into Java, in so much both are riddled with security holes.<p>Longer-term view: Rails mocked the Java web eco-system in the early days because it was 'Enterprise', and Rails was the scrappy upstart with magic commands to scaffold a blog in 5 mins and show screencasts to the world. This sold a lot of books (without it would Pragmatic Programmer have even had a book store?). Slowly, the rot set it, and the once light and nimble Rails become bloated as everyone added their pet features, their design pattersn (even though they would never call them that - that is <i>so</i> Java!), and the too-many-cooks-in-the-code-kitchen sprinkling so much magic and syntactic sugar around the codebase it practically causes diabetes.<p>Rails solved a problem for the company that wrote it. Since then people have been trying to shoe-horn it work with their business problem, and then found once they now have two problems.<p>The rest of us moved on.

"RefineryCMS, Devise, Omniauth, Carrierwave, Unicorn, Rack Rewrite, Fog, New Relic, Foreman, AMQP, and Honeybadger, not to mention the extra magic that Heroku gems throw into the mix (backups and other fun)."<p>Just going through all those names makes me tired. Its like framework names are to software as band names are to bands.

Java is like a truck, Rails like a bicycle. Rails cannot turn into Java because it lacks the capabilities to turn into Java.