
Rails Has Turned into Java - urlwolf
http://discursive.com/2013/02/19/rails-you-have-turned-into-java-congratulations/
======
lkrubner
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:

"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."

<http://www.artima.com/weblogs/viewpost.jsp?thread=141312>

~~~
adventureloop
I know it is not the mode to comment to mention your own up vote.

Rails might have deteriorated in ease of use, but I cannot imagine it being
worse than Java EE was in 2004. Modern Java EE is a world of pain, even simple
apps are difficult to build. The entire front end stack is antisocial,
difficult to extend and anachronistic.

I don't think anyone working with a modern java web stack could read this post
about rails 'being like java' without a dark chuckle.

~~~
currywurst
Have you tried Java EE 6 ? JAX-RS in particular is a _splendidly_ designed api
for RESTful services. And then you can make single page apps instead of JSF.
This method is even going have ide support in Netbeans 7.3 with wizard-driven
Backbone/Angular app generation.

~~~
mbell
JAX-RS is really nice for building APIs and I actually prefer the way it works
to Sinatra, especially if using it with Groovy.

But, this isn't Sinatra vs EE6, its Rails vs EE6, so its not a proper
comparison.

To compare with Rails you've got to look at other parts of EE6: JSF + CDI +
JPA, which is an awful mess. JSF by itself is enough to kill its usability for
many modern applications, the amount of state JSF carries around is
ridiculous.

~~~
tmo9d
Ah, watch out for JSF, it's a dangerous place. JPA on the other hand is
surprisingly good these days try Spring 3 Oliver Gierke has done good things.

~~~
mbell
JPA is fine, if and only if you've got a framework managing the entity manager
lifecycle for you in a reasonable way.

In my opinion if I need an entire separate framework (or container) to manage
it, I think its broken. I've switched to Ebean for Java ORM and am vastly
happier now.

JPA also gets the award for the worst programmatic query building API I've
ever seen. As a result it seems like the majority of people just use JPQL
strings which is really annoying as its also SQL but not quite SQL.

------
kevinconroy
No, Rails hasn't turned into Java. Rails has matured into a complex ecosystem.
Java has also matured into a complex ecosystem.

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.

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.

~~~
tmo9d
I added in a note, I think this is the multi-year result of not having a old,
grey-haired standards committee around creating APIs. I made fun of Sun and
Oracle for doing things like this for years, but after futzing around with
Rails frameworks, integration, and edge-cases. I think I would have preferred
to have people sitting around a conference call saying things like, "Hey
Devise people, your authentication approach looks like a good standard, why
don't we formalize it so we can make this stuff easier to integrate."

I know this makes me sound old. I own that.

~~~
kevinconroy
I, for one, welcome our W3C overlords.

~~~
tmo9d
Oh c'mon it's much much worse than that. Oracle runs the JCP not the W3C.

And, yes, I admit it, I'm a jerk.

------
RyanZAG
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.

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.

Any language can be used for a small project and work very well - precious few
can still continue to work well at scale.

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.

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.

~~~
fleitz
The whole point of rails is not to build massive projects. If you're building
massive projects with thousands of classes on rails then you should be all
means switch to J2EE.

~~~
cglee
This needs to be repeated over and over. We see so many pundits pushing the
"right" way to build Rails applications now. Rails was a reaction _against_
large applications. The major use case is to build CRUDs in front of a db. If
your application out grows Rails, it's not a condemnation about Rails, or your
team, or an earlier choice.

If you're Twitter or Facebook, don’t use Rails out of the box. For the rest of
us who _want_ to work on small applications, Rails is still beautiful. And
when I say small, I mean applications around the complexity of a Basecamp or
Github.

~~~
fleitz
Fully agree, the next boogey man against rails is performance which again is
quite a silly argument when you have customers and servers cost $5 / month.

------
lkrubner
The pushback against Ruby/Rails has been building for a long time. There's
always been jokes about Ruby being slow:

<http://harmful.cat-v.org/software/ruby/>

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.

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:
[http://tonyarcieri.com/2012-the-year-rubyists-learned-to-
sto...](http://tonyarcieri.com/2012-the-year-rubyists-learned-to-stop-
worrying-and-love-the-threads)

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:

<http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto>

Even though the tone is insane, he made some points that stuck in people's
heads, including mine. This was important to note:

"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:

(15:11:12) DHH: before fastthread we had ~400 restarts/day

(15:11:22) DHH: now we have perhaps 10

(15:11:29) Zed S.: oh nice

(15:11:33) Zed S.: and that's still fastcgi right?

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."

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".

~~~
phillmv
Uhm.

We deployed a new server last night.

`cap staging deploy:setup` `cap staging deploy` `cap staging deploy:migrate`

You do have to know how to setup Unicorn but…

~~~
throwawayG9
He's talking about installing the web server, not deploying the application.

Deploying an application can be done with 1-3 commands in _any_ language,
since it has little to do with the language itself. All you need is a build or
deployment script, which can be written in Bash or whatever.

~~~
phillmv
I realize, but that too is a constant per platform. It's about the same amount
of effort per web server per ecosystem, since in our we case we reverse proxy
to the application server.

If we're talking about shared hosting, that's a whole different ball game.

------
danielsju6
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.

I don't use Refinery, Devise, OmniAuth, Unicorn, Rack Rewrite, Fog, AMQP, or
Heroku.

I use Passenger with Apache or Nginx, self-host, and write my own core
functionality like authentication.

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.

Dynamic typing: if you treat Rails like Java, it acts like Java.

~~~
stuff4ben
So what you're saying is you like to re-invent the wheel? Suffer from "not
invented here" syndrome much?

~~~
gfodor
No, what he's saying is that engineering is about tradeoffs. Adding another
framework introduces another node in the graph, and n edges. If you don't need
fancy authentication and are pretty confident you never will, then don't add
devise. If you don't know or understand why you would use some bleeding edge
web server or framework, use what is well-understood and has the least moving
parts.

------
Skoofoo
> 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).

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.

~~~
tmo9d
But, Devise is one of the better frameworks out there. Along with Omniauth it
saved a huge amount of work. I'd reconsider Devise and look at Omniauth, it is
a huge time saver.

New Relic is awesome, but expensive and they do have an aggressive marketing
automation thing going on with the emails and such. But, you can't blame them
for that, they have to pay the bills and more power to them for that.

~~~
Skoofoo
I think it's a matter of personal taste. Devise is a pretty large library that
deeply entrenches itself in your application and expects you to do things in a
certain way. I personally don't think it's worth the added complexity, instead
I prefer using standard Rails features [1] to build exactly what I want. But
then, others may feel it's not worthwhile to even use Rails and instead prefer
to use Sinatra or Flask. Every developer seems to have their own comfort zone
in terms of how much control they have. For instance, Linus Torvalds won't
even use C++ over C [2].

Omniauth looks like something I would use, though.

As for New Relic, I certainly can blame them for spamming. I realize that
everybody's gotta eat, but there is no excuse for them to send me "I wanted to
connect regarding your interest in the New Relic trial. So far I have not been
able to successfully reach you." after I already sent them two emails telling
them to stop emailing me. Annoying anyone who hands over their email doesn't
strike me as a particularly ethical business strategy.

[1] [http://www.farbeyondprogramming.com/2011/05/rails-user-
authe...](http://www.farbeyondprogramming.com/2011/05/rails-user-
authentication-using-has_secure_password/)

[2] <http://harmful.cat-v.org/software/c++/linus>

------
squidsoup
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.

~~~
tmo9d
I suspect that your suspicions are wrong because I wrote the article and I
spend much of my day writing both Java and Ruby. I just find it easier these
days to work with Spring 3. Why? Because the Spring and the Oracle folks
reacted to Rails pretty quickly and came up with a lot of solutions that might
surprise you.

It takes just about the same LoC now to do in Spring what I'm doing in Java.
The difference is that the performance in Java is much higher.

~~~
squidsoup
An article comparing Spring 3 to Rails, enumerating some of those solutions,
would have been more informative.

------
davidw
Flame-bait title if I've ever seen one.

Let's see an actual comparison with some numbers:

* Lines of code, and number of tasks necessary to get a development environment set up.

* Memory used with one client accessing the system, and with, say, 10 clients accessing it.

* Some performance benchmarks.

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.

~~~
tmo9d
You want that. Ok? I'm not sure you are going to like the results. But, if you
want a follow up, I'll happily supply it.

~~~
davidw
Rails is probably not going to do well in the performance department, but I
think the other metrics would be interesting to see, and require actual
research, rather than just whipping up an attention-gathering headline.

------
throwaway420
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?".

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.

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.

~~~
VeejayRampay
Rails is just the sweet spot for low enough bar of entry, power and
expressiveness. It also offers you a proven way to get up on your feet easily.

But well, it's a fashion thing. People need new things, people need to kill
the father, people need new chapels. Nevermind that what we have right now
does the job perfectly and is lots of fun, we need something NEW.

~~~
tmo9d
I don't know. I'm running a business on a Rails site and it's sort of sucking
right now in terms of what I can get done and how fast I can get it done. Why?
Because learning rails isn't the easiest thing in the world any more
especially when half of the application is custom work around to jury-rig
different frameworks together.

One of the developers came to me just last week and showed me a POC in Java
that was cleanly assembled, easy to understand, and lacked all the enterprisey
stuff that scared me away from Java years ago. That's why I wrote the article.

I'm not burning the chapel to build a new one. I'm setting sail for the
fatherland in search of Silk and Spices. (I didn't mean to make sense with
that ending, but you read it, didn't you?)

~~~
VeejayRampay
It's surprising that you talk about "learning" Rails though.

I am not an entrepreneur so take this is a shovelful of salt, but I wouldn't
venture into creating a business on a technology that I have to learn along
the way.

Also, I am now confused that Rails is turning into Java, yet you recently saw
a beautiful piece of Java. Rails is just like Java and its "darker" Enterprise
Side ™, you get to pick and choose what you want to use, no one is forcing
RefineryCMS and Devise and whatnot down your text editor :D

------
vampirechicken
It's the age old set of trade-offs between buy and build.

Build it all yourself and it takes forever, but you understand it all.

Buy it from somebody else, and you get it quickly, but you're at their mercy
for efficient understandable code.

No language or framework is immune. Enjoy your java.

~~~
tmo9d
I don't think it's the build vs. buy trade-off, I think it is more a question
of efficient platforms for vendor collaboration resulting in the emergence of
voluntary standards that create efficient and open markets kind of problem.
Ruby has a DIY ethic which is respectable, but there's little infrastructure
to support market-wide discussions throughout the ecosystem.

Really, if you want to make analogies. Rails is essential loose federation
covered under Articles of Confederation while Java is to be appreciated as a
strong Federal system that allows for states to innovate.

------
t4nkd
He's trading most of the simplicity for rich pre-rolled features.

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.

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.)

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.

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.

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.

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.

Really, you traded simplicity for rich features out of the box. Hopefully you
took the time to figure out if you actually _need_ those features before
integrating them with your app. Also, Refinery's Engine architecture is
kind've hair brained.

(P.S. on chrome 24.0.1312.57 and Mountain Lion the dynamic length comment box
on this blog is totally fucked.)

------
calinet6
"... Java, have you learned to easy yet?"

No, it hasn't. That's why we're using Rails.

And to be honest, it ain't that bad.

~~~
taligent

       "... Java, have you learned to easy yet?"
    

Try Play, Grails, Vert.X.

And you know what it isn't easy. Having to deal with Ruby's dependency
nightmares.

~~~
spellboots
Dependency management in ruby is trivial with bundler.

~~~
taligent
For small, single apps sure.

But if you have large apps with multiple Ruby versions then dealing with
rvmrc, bundler and gem incompatibilities is a nightmare.

Java's forward compatibility is a lot more robust.

~~~
jdminhbg
You have an app with multiple Ruby versions?

~~~
taligent
Yes. I take it you've never worked at an enterprise company before ?

Every time a new developer comes on board they just love to add new technology
X and then in the years to come other developers add Y and so on. Of course
there are developers who have to manage this.

~~~
calinet6
Enterprise company? Ha. Just try dealing with three different decade-old JVM
versions _once._ You'll pray for bundler.

------
javajosh
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.

~~~
dasil003
This has got to be one of the worst analogies I've ever seen. One of Rails'
core strengths is that it is written in Ruby which makes _anything_ , even
batshit-insane dynamic runtime monkeypatching possible. Not that anyone would
advocate doing that as a matter of course, but the point is nothing is out of
reach in a Ruby app.

~~~
javajosh
Rails has monkeypatching. Access has COM.

Inbound developers will not be able to use either of these things because
their skills and expectations have been set by that easy 80%.

~~~
danielsju6
Monkey-patching really? You're forgetting what else Rails has in our
ecosystem: Github.

1.) Fork a project on Github, say the push notification gem
<https://github.com/jpoz/APNS>

2.) Alter behavior in your branch <https://github.com/jamesdaniels/APNS>

3.) Optional bit, send a pull-request with your changes

4.) Vendor it or require your fork in the Gemfile: gem 'apns', :git =>
'git@github.com:jamesdaniels/APNS.git'

Tada!

~~~
mtarnovan
shortcut:

gem 'apns', :github => 'jamesdaniels/APNS'

~~~
danielsju6
Nice.

------
lobster_johnson
Sorry, but this article is bullshit.

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.

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.

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.

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.

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.

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).

[1] <https://github.com/bengler/checkpoint>

[2] <https://github.com/bengler/grove>

[3] <https://github.com/bengler/kudu>

[4] <https://github.com/bengler/snitch>

~~~
tmo9d
You are joking right, "Try not to stuff your app with everything you can
possibly think of." Like providing a admin interface on Refinery as well as
authentication with Devise is "everything and the kitchen sink".

I think you may be trying to defend something.

~~~
grey-area
Have you used Refinery? I have and wouldn't base an app on it, or even use it
again for a CMS - frankly you could build the same admin features better in
Rails in a couple of days, and tailor them properly to your application.
Refinery is not a good model of a rails app and is probably the main reason
for his problems or perception that Rails is heavy - it was a mistake to try
to base an app on it and most of his gripes seem centered on that - there's a
lesson there and it's not about Rails.

Rails has become lighter with 3.x and will become lighter still with 4.x -
they're dropping a lot of unnecessary stuff and trying to pare it down to the
minimum - an admirable direction and quite the opposite to Java, which makes
this article all the more baffling. Of course it's not the perfect framework
and there are plenty of options, but the complaints of the article are
histrionics.

The laundry list of possible technologies in the article is absurd -
RefineryCMS, Devise, Omniauth, Carrierwave, Unicorn, Rack Rewrite, Fog, New
Relic, Foreman, AMQP, and Honeybadger, Heroku.

You can get started with rails on a cheap VPS and serve your first few hundred
thousand users with the following very simple stack: _Apache, Ruby, Passenger,
Rails_. Setup is a few lines in your package manager of choice, writing the
app is straightforward and requires none of the software above, maintenance is
running aptitude update and bundle update now and then.

Out of the stack above, Devise is quite a nice authentication solution and is
the only one I'd recommend, but it's easy to roll your own, as to the rest of
his list, if you don't need it, don't bother using it, none of it is required.

~~~
tmo9d
"An admirable direction and quite the opposite of Java." What are you talking,
specifics please? Is Java a framework with features comparable to Rails?

Why is the laundry list of technologies absurd, these are the technologies
that I run a business on. I think what's absurd is the level of reaction in
your comment. Rails people now have this defensive reaction, and I've noticed
it in person as well.

It reminds me of the reaction of Java zealots in 2007. It really does. "Oh,
really, you couldn't be serious, I mean it's absurd to think that Ruby...." It
wasn't absurd to challenge, and neither is this challenge.

~~~
grey-area
Firstly, apologies for the harsh tone and references in the 3rd person as I
see from your other comments that you are the author of the article.

 _"An admirable direction and quite the opposite of Java." What are you
talking, specifics please? Is Java a framework with features comparable to
Rails?_

I admit this was sloppy wording, however your article is called 'Rails, You
Have Turned into Java.' :) I was comparing Rails 4 (removes lots of
features/bloat), with Java Frameworks which do not have a reputation for
slimming down... Of course I'm sure there are some minimal Java web frameworks
out there too (sorry not familiar with many). Your article is somewhat
provocative and not representative of the experience of many with Rails so I
wouldn't be surprised if you encounter a defensive reaction to this sort of
sentiment. That's to be expected, as was the reaction of those using Java
frameworks to DHH's blowhard rhetoric when he started out with Rails.

 _Why is the laundry list of technologies absurd, these are the technologies
that I run a business on._

They're absurd as a criticism of Rails because many of them are completely
external to Rails, not required to run a website/app, and some of them are not
the right choices IMHO. Rails does not require any of these components to run
websites even at scale. Sure some of them might be useful, but none are
essential or intrinsic to Rails.

Forgive me but I think the choice of RefineryCMS was a mistake, and if you
back out of that mistake, you'd find Rails a lot more forgiving, a lot
lighter, and a lot more suited to what you want to do if you're writing a
large webapp with lots of components (or several interacting webapps).
Problems with engines, subapps, conflicting routes etc are all based on this,
and simply don't occur in most Rails apps. I've used it as a CMS for some
clients and regret having done so in retrospect - it's not terrible standalone
(also not great) but I can see how integrating it with an app would be a
nightmare. You don't need to use meta-frameworks built on Rails to build an
app, in fact I'd say it's a mistake, use a few discrete gems like devise, and
just build what you want.

------
mark_l_watson
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.

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.

It seems better to have to write a little more code, but layer on top of much
small libraries/frameworks.

------
primitur
You know what has become the "Best Java" for me?

Lua.

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.

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.

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.

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.

------
rzendacott
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?

~~~
static_typed
If you love constant patching for the daily critical security holes, stick
with Rails. If you love worrying where they have stuck yet another Yaml
parser, and where else they are eval-ing user supplied data, stick with Rails.

If you prefer a bit of an easier, less-stressful life, there is hope with many
of the Perl, Python and PHP frameworks.

~~~
squidsoup
Like the Django patch that was released yesterday?
(<https://www.djangoproject.com/weblog/2013/feb/19/security/>)

The fact that the Rails team quickly responds to vulnerabilities should be
reassuring not a disincentive to use the framework. All software is subject to
vulnerabilities - the recent issues with YAML are a class of exploit common
across many frameworks in different ecosystems (Django's TastyPie had a
similar issue in the past).

~~~
static_typed
Yes, Django took a solid step to properly fix the underlying issue, rather
than apply many small sticky-plasters over several days instead, leaving the
same basic vector open in the meantime. In fact, the Django issue reported was
posted on HN yesterday and the comments on that posting underline what I just
said here.

Remember - Python for Pros, Ruby to pose.

~~~
slurgfest
I'm a big Python fan but that closing remark is just an incredibly obnoxious
thing to say and is only going to feed the Python haters

------
neya
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.

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.

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

~~~
ef4
I actually had to write some Java recently for the first time in about ten
years. I was hoping that the evolution of the language would make it less
painful than it used to be.

I was unimpressed. Generics are better than nothing, but still dramatically
worse than having a reasonable syntax for anonymous closures. The newer
iterator syntax is better than nothing, but still maddeningly lacking in the
most basic type inference -- any compiler that can't infer the type of "thing"
here is stupid:

    
    
        ArrayList<MyClass> list = this.buildList();
        for (MyClass thing: list){
            ...
        }
    

The programmer is still forced to overspecify and manually convert between
types like ArrayList<Thing> and Thing[], even though 95% of the time the
difference has no impact worth thinking about.

I could go on, but my point is that people like me who dislike Java dislike it
for fundamental reasons. We're not going to be converted, because the changes
we would demand would probably horrify Java's core audience.

~~~
taligent
> even though 95% of the time the difference has no impact worth thinking
> about.

Because the 5% of the time matters when you have a language that needs to run
on everything from mobile phones to supercomputers.

I personally much prefer being explicit about what I want to happen.

~~~
jfb
No non-trivial application ever, _ever_ been WORM.

------
geebee
"Rails isn't the easy framework it once was..."

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.

"Sure, Rails itself is straightforward, but the frameworks you slap on top of
it can quickly become burdensome abstractions"

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.

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.

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.

~~~
tmo9d
Spring 3 is excellent BTW. I originally started to blog about a Spring 3
application I wrote, but then it turned into this Rails rants.

And, I don't hate Rails at all. Really. I don't.

~~~
geebee
Definitely write the Spring 3 blog post! I can't get deep into it right now,
but I'd be interested in an overview, especially from someone who uses Rails
as well.

------
mping
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!

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.

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).

Anyway, I still like rails, I just think they were a bit premature in judging
the java camp...

------
cmbaus
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.

Once an application, no matter the language, has a significant number of
external dependencies deploying it becomes a challenge.

------
Legion
Post title seems like it should be, "Refinery is a messy CMS".

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.

------
throwa
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.

In reality most companies are polyglot using different languages, tools and
frameworks for different features in their stack.

I am personally tied of unnecessary rants. There is no perfect programming
language or framework.

Abandon the notion that there's a "right framework," and just choose one and
get hacking.

------
jscheel
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.

------
joedev
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".

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.

So yes, if you try to avoid Rails' conventions, you will have trouble. But
it's not Rails' fault.

------
joedev
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.

------
hnwh
hope that means I have job options for another decade

------
static_typed
Cheapshot: Rails HAS turned into Java, in so much both are riddled with
security holes.

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 _so_ Java!), and the
too-many-cooks-in-the-code-kitchen sprinkling so much magic and syntactic
sugar around the codebase it practically causes diabetes.

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.

The rest of us moved on.

------
Amanda_Panda
"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)."

Just going through all those names makes me tired. Its like framework names
are to software as band names are to bands.

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

~~~
tmo9d
No Java is like a Lepton and Rails is like a Neutrino. Neither interact with
the Strong force. Got it?

