Ruby vs Java, which wins?

July 30, 2011 2:22 PM

How does Ruby compare to C#/Java in terms of speed of development, quality of code and long-term maintainability? A broad question, I know, but my focus is on enterprise applications that might pull in from several large data sources and might be rather large.

I've played around with Ruby and Ruby on Rails. It seems like my gut is telling me that apples to apples, given the same project in Java or C#, I could get things done Ruby at least 1/3 quicker, and have just as high code quality and maintainability. It seems that the big barrier to doing this is that there's not that many good Ruby developers out there, so adding members to the team is going to be a challenge,

Is this really the only barrier? Has anyone out there done a large project, with multiple team members, in Ruby? I guess in my mind I'm seeing the leap from Java->Ruby the equivalent of C++->Java (I'm assuming that C#/.Net is near equivalent to Java in development time).

Again, I realize there's probably some performance issues, especially as sites get larger, but that's not really a problem I face. I'm more interested in that if you had two teams with the same amount of experience, tasked with building an e-commerce site from scratch, would you see one with a better work product at the end, or would it be about the same?

One of things that's spurred this is that while my gut says Ruby development is quicker, I've seen quite a few Ruby shops fail. Complete confirmation bias on my part, I realize, but it is still something I've seen.

posted by geoff. to computers & internet (15 answers total)

Well, obviously Ruby's big advantage over Java is you can write the equivalent code in fewer lines. This has an advantage both in terms of speed of development and in terms of bug-fixing (assuming you buy the conventional wisdom that number of bugs per line of code is roughly constant across languages and developers).

The disadvantage is you have to write unit tests. "That's not a disadvantage!" some people in the audience are reflexively saying, and in some sense they're right: if you do write the unit tests, you get better checking and refactoring support than what you get from static types and compilation. But then you're effectively counting the unit tests as part of your code base, and you lose some of your lines-of-code savings above, since you now have to develop and maintain (and test!) the unit tests. And if you don't write the unit tests, you're much worse off* than the Java situation: it's very easy to break things accidentally and you won't find out until runtime.

*You have to make your own tradeoff between speed of development and safety, of course; but as the number of people on the team scales, you have to put more effort into safety unless you can count on everyone else on the team 100% as much as you can count on yourself.

So the upshot in my experience is Ruby (or Python or Perl) development is quicker than Java (albeit not as quick as it seems at first) but it requires more discipline from the team.

(I actually think that C#, with anonymous methods and LINQ for functional support, is a great compromise, but if you're in an environment where you're picking between Ruby and Java, C# probably isn't an actual option.)
posted by inkyz at 2:53 PM on July 30, 2011

OSCON 2011 just happened this week. There were a lot of presentations Re: Java, Ruby, Big Data, etc. I haven't caught up on all of them yet, but a few were about migrating from Ruby to Java (for the BIG scalability issues with Ruby), and some of the big Ruby shops no longer looking for Ruby programmers (in particular), prefering to ask for generically good programmers to teach Ruby instead. I'm not sure if any of the talks relate directly to your question of speed/teams.

Any other MeFi geeks should probably check out the presentation list if they weren't aware of this conference.
posted by zengargoyle at 3:23 PM on July 30, 2011 [1 favorite]

You should absolutely have unit tests regardless of implementation language. And the code productivity advantage of Ruby would also apply to writing the unit tests.
posted by Hither at 3:28 PM on July 30, 2011

I've seen quite a few Ruby shops fail

I have a theory about this. I'm not a particularly experienced Ruby developer, so I can't claim expertise, but it has some analogues to areas where I do have more experience, so I'm going to throw it out there for consideration.

I think the productivity magnifiers of Ruby and Rails (and, in general, "dynamic" languages and web app frameworks) are both real, and that they provide a particular boost to developers who have little to middlin' amounts of experience. That magnifier can bring a lot of projects within reach than might have been otherwise unavailable, and so they start up shops and actually do pretty well with what they attempt for a while.

And then... they encounter requirements they're not equipped to handle. The complexity of the systems pile up. The demands on it increase. They need solutions that require a depth of understanding of either the framework or the language that they don't have (or, potentially, performance that neither are likely to yield). Everything's been fairly easy up until now... and because of this, it might even be that much more of a shock to find they're in a situation they're just not prepared for yet.

I don't think this is universal, though. I've also met some very strong Ruby developers. Most of them, though, don't tend to be strictly Ruby developers per se so much as they are developers who found Ruby and decided they favored it. I kindof feel this way about programmers in general, actually... most of the good ones are comfortable across a variety of languages and will figure out how to get the job done with whatever is at hand or makes sense, even if they have their own preferences. This is one thing I'd look for in adding anyone to a team or hiring any shop to help out, largely because it's an indication you're not just getting someone who found the Ruby-flavored kool-aid stand on their way into the industry, but someone with broader experience that will enable them to get things done when they hit the ceiling of what's easy.

The disadvantage is you have to write unit tests. "That's not a disadvantage!" some people in the audience are reflexively saying, and in some sense they're right: if you do write the unit tests, you get better checking and refactoring support than what you get from static types and compilation. But then you're effectively counting the unit tests as part of your code base, and you lose some of your lines-of-code savings above, since you now have to develop and maintain (and test!) the unit tests. And if you don't write the unit tests, you're much worse off* than the Java situation: it's very easy to break things accidentally and you won't find out until runtime.

This is a really good summary, but I'd respond with a few points which drive some of my own preference for the dynamic language side of things:

* The kind of errors a typing system like Java's catches are somewhat shallow, and my own experience (YMMV) is that since a few years into programming, I've been less likely to make them, and more likely to make mistakes at the level of a model of behavior the type system doesn't work in. If I decide I want automated detection of these kinds of like Java or C# to catch that, I'm going to have to write unit tests anyway.

* When I do make the rare type-related mistake, I find it usually manifests itself fairly obviously. There are some exceptions (some issues related to the fuzziness of various kinds of falseness in JavaScript come to mind), but I honestly just can't remember sweating over this on more than a handful of occasions.

* Runtime comes much faster with a dynamic language than with a compiled one. :)

* While unit tests do add to codebase size, they're generally loosely coupled enough that they very rarely add much in the way of complexity (which is the big deal, IMO). And due to the code compactness of dynamic languages they add less to the code size than they might.
posted by weston at 4:01 PM on July 30, 2011 [5 favorites]

I am an experienced Ruby dev who has worked in a Java shop before ad I think everything weston says is pretty spot-on. Rails lets mediocre coders get further with less, with more spectacular failures down the road.

I also think Java devs are more likely to have studied programming in an academic (or very corporate) setting, while RoR is wonderfully available and halfway easy to pickup without much background. I'm sure this also contributes to their cultures and what you can expect from both camps.
posted by soma lkzx at 5:37 PM on July 30, 2011 [1 favorite]

I am an experienced Ruby dev who has worked in a Java shop before ad I think everything weston says is pretty spot-on. Rails lets mediocre coders get further with less, with more spectacular failures down the road.

I work with experienced devs who all have CS or math degrees and have years of programming experience. We also are very comprehensive in our tests, which is why the away from a statically typed language isn't that big of a deal.

I assume you work with other Ruby devs who are experienced and not mediocre? Do you guys work better/more efficiently? Or is it simply like buying a nice car. Sure a BMW is a pretty nice ride and all, but a Camry gets me going to where I am just the same.
posted by geoff. at 5:52 PM on July 30, 2011

I keep hearing Python is the new hotness these days.

Anyway, the language you'll be fastest with is the language you already know. A good Java programmer will outperform a mediocre Ruby programmer, and vise versa.

The other way would be to look for developers who have experience with even harder new languages like Haskel, Erlang, Scala or Clojure. Developers with those skills will be more likely to be people who really get into programming.
posted by delmoi at 10:40 PM on July 30, 2011

Anyway, the language you'll be fastest with is the language you already know

no, the stack you'll be fastest with is the stack you already know. take a RoR programmer and put them on a team working with sinatra/sequel and they'll be lost. or put me on a java team and I'll write java code for you tomorrow, but I'll spend half my time poking through the class library documentation (and the other half bitching about java, so don't hire me for a java project).

if you're hiring Ruby devs., I'd suggest passing on anyone who only knows the Rails stack. knowing how to apply Rails to problems that Rails can solve, but never having looked beyond that nice cozy comfortable space, tends to be a sign of someone who drank the KoolAid (as weston put it).
posted by russm at 4:53 AM on July 31, 2011 [1 favorite]

also, what delmoi said about other languages.

(but "new languages like Haskel, Erlang"? in which world are those new languages?)
posted by russm at 4:59 AM on July 31, 2011

I love Ruby, I think it has the most readable code of any language, and has the least number of surprises and restrictions. So for developing something unique, or from scratch, I think it is close to the ideal language (at least for me).
Rails is a different beast, and I would say Rails is an excellent framework for building database driven web sites. However, if you are building something other than a database driven web site, Rails tends to lose some to all of its luster depending on how far away you get from its sweet spot.

Ruby also has a humongous set of libraries (gems) that make it super easy to leverage solutions that others have already developed. In my opinion, this is also one of its weak points. It's incredibly easy to leverage other libraries, and this is where I think Ruby can sometimes run into problems in production systems. If you're running a production system, it's your responsibility to make sure any dependent libraries are production ready as well. And that any libraries those libraries use are production ready, etc. This is not a unique issue to Ruby by any means, but the ease that libraries can be built and leveraged means it's more of a problem.

On the plus side, if an issue with a dependent library is found, it is *usually* easy to get the maintainer of that library to update it. This provides a huge community benefit as it allows for libraries to rapidly stabilize, but also creates a path for an insidious problem.

Let's say you found a bug in a parser library (v1.2) you were dependent upon and provided a patch to the maintainer. The maintainer of that library will typically look that patch over and pull it into their next release, and run their libraries tests against that patch, but several releases may have occurred between your version and the current version, say parser v2.1 for this example. The insidious problem is that your software may work fine with parser v1.2, and the parser v2.1 library may pass all of its tests with your patch, BUT that doesn't mean that your software is compatible with parser v2.1. Maybe one of the classes you used changed its interface in parser v2.0. Now you are left with the choice of using v1.2 with your patch, and you being the only one to maintain it. Or refactoring your code to be compliant with v2.x of the library so you don't have to deal with maintaining a one-off library.

One dependency hell problem that Ruby did solve (with the awesomeness that is the builder gem), is that if you had dependencies such that your software depended on library X v1.2, and library X depended on library Y v2.1, but your software also depended on library Y as well, but it needed v1.9 (and broke on v2.0 and above); ruby (with builder) is smart enough to keep those dependencies separate. Without builder, you'd still have a dependency issue though.

It's my opinion that these complicated dependency issues are one factor that makes complex ruby projects a bit brittle sometimes.
posted by forforf at 11:44 AM on July 31, 2011

A similar discussion's going on at Reddit today. For some reason I ended up contributing a few screeds.
posted by vsync at 12:43 PM on July 31, 2011 [1 favorite]

I really disagree with the notion that Java's typing is a trivial feature and that simply adding unit tests can make up for it. I think this works as long as you have a small number of devs and a small number of libraries. Once you're dealing with a library developed over several cycles by several people, some of whom may no longer be around, being forced to go through unit tests and call sites to figure out what exactly is being passed around becomes anything but trivial.
posted by bjrubble at 1:51 PM on July 31, 2011

Do you guys work better/more efficiently? Or is it simply like buying a nice car. Sure a BMW is a pretty nice ride and all, but a Camry gets me going to where I am just the same.

I don't know if you've read Steve Yegge's writing, but talking of his time in Amazon's Customer Service Applications group, he says:

One thing I observed was that the folks who favored Perl always seemed to be able to get stuff done really, really fast, even compared to experienced Java folks. And they had their act together; it wasn't just crude hackery, as many Java programmers would like to believe. Their code was generally very well organized, and when it wasn't, they'd go in periodically and fix it. Sometimes they did quick, hacky scripts, and in fact the ability to do this proved to be mission-critical time and time again. But generally the Perl stuff worked just as well as the Java stuff. Whenever performance became an issue, they'd find clever ways to make it perform well enough.

Matches my experience with web development (less so for desktop apps), I suspect Perl is a reasonable stand-in for Ruby for the sake of comparison with Java.

As for frameworks... I wanted to moderate my earlier comment that "they provide a particular boost to developers who have little to middlin' amounts of experience," which I think could read for the idea that they don't have much to offer for experienced developers. From my own limited experience and in talking to acquaintances, they do offer a boost there as well (mostly in obvious ways: standard organization, which makes things easy to find and reduces the friction from organization decisions, and of course re-use of common components that have been vetted by a community), but it may be that boost tends to be front-loaded to the start of the project. Nothing to sneeze at, but I think the point is that eventually, for most custom apps, you're going to have to do work somebody else hasn't done for you. No surprise, really. :)
posted by weston at 8:02 PM on July 31, 2011

When people say Java, they mean quite a few things. Most people assume you mean the language, but it's really the JVM and core libraries that make it fast and everyone's got their pet changes to the Java language that make it more like Python/Ruby (Groovy, Scala, etc). It should be possible to combine Django/Pylons/Rails and the JVM and get the best of both worlds. Whether people are investing the effort to make these guys run well on the JVM, I can't say.

PS. I really hate unit tests. They scale poorly as you make more and more components and interfaces. What I favor is static analysis (lint, FindBugs) and integration tests. Integration / behavioral tests are great because they easily translate into service checks.
posted by pwnguin at 8:13 AM on August 1, 2011

Came across a blog post that seems apropos to this discussion to me:

"Here’s the dirty little secret of Rails development: the messiest, nastiest big-ball-of-mud code I have seen in my entire career has been in Ruby on Rails projects. I’ve seen Rails projects that accumulated enough technical debt and waste in two years to make 10 year-old C/C++ programs look clean and elegant by comparison. And it wasn’t just one project. I’ve seen it over and over.

In a way I think this is a testament to the power of the platform...

Unfortunately, as a result a lot of projects I come to on have hit what I think of as the productivity crash. At some point the cumulative effect of all those little shortcuts catches up with the development team, and changes that would once have taken a day start taking two weeks as all the dependencies and unintended consequences are sorted out."

But it's not all negative:

"The truth is, Ruby on Rails projects are exceptional in a way: they are really small... There are a few reasons for this. Ruby is a more expressive language than, say, Java, so to some degree Rails projects will always be smaller than equivalent projects in higher-ceremony languages. Ruby is still a wonderful language, and the terrific thing about it is that it adapts to large-system design patterns remarkably easily, and with very little ceremony."

Food for thought.
posted by weston at 11:16 AM on August 22, 2011