Brace No More - Going From Java to Ruby on Rails

Before I came to Netguru, I was a freelance C# and Java/Android developer - and let me tell you, I liked both of these languages (C# more than Java, though - love me some lambdas and LINQ!). I even liked Eclipse, which was my IDE of choice, which, according to many, puts me in the group of people better known as masochists.

But I digress.

The transition from Java to Ruby wasn’t the easiest thing in my life, and at first I had many doubts about what I was seeing. Take even the most basic thing about how the code blocks are written: braces vs. indentation.

Let’s take a look at some code I wrote long ago:

Now let’s try to do something similar in Ruby on Rails (now, this isn't the Rails-way, it's more like a literal translation here, folks!):

how I wrote it at the beginning

how I’d write it now

When I began, I had huge problems with not sticking the braces everywhere. And don’t even get me started on the bloody buggers called semicolons - those were especially hard to drop, and caused a great deal of frustration early on.

But after you get out of this unhealthy relationship with the braces and the annoying little buggers, and get over the fact that you need to keep track of how you actually indent things because it matters - ruby is a blast to write in.

Still, there were some things that caught me off guard:

• Like the whole return business, for example. It was very cool to learn that every method in ruby will return a value by default, and you don’t need to specifically tell it to return something all the time. Instead, it just takes the value obtained in the last line and returns it..

• All member variables are not accessible from outside of the class. This is another thing that I complained about at first, but started to respect very quickly. If you want to get your hands on it, you write a method.

• It’s nil instead of null. If you have to write some javascript code next to your ruby code, this can get messy very quickly. Plus, the whole “javascript uses braces, brackets and your favorite little semicolons, deal with it” attitude thing it has going on. This is why so many Rails developers use coffeescript instead, it makes switching between them a bit more bearable.

• The each and the for. In Java, the ‘for’ loop is a basic tool, you see it everywhere. It has its own variable scope, easy syntax, and you can break out easily. I haven’t seen a ‘for’ loop in ruby code even once (outside of basic showcase examples). The difference is, surprisingly, scoping.

each

for

• Another fun thing tidbit: The Rails community tends to loathe XML - this made me a very happy person. I deal with JSON and YAML daily, and the last time I had to look at an XML file was over a year ago. Now, it’s definitely not true for every single RoR project on the planet. Sometimes you just have to deal with this hellspawn of a format, but if we’re speaking about personal experience here, I couldn’t be happier. Compare this to what you have to deal with while developing Android apps, for example. Sometimes I think about going back, and this memory kills that thought process like it had never even happened.

Things that I knew going in and thought were awesome:

• Everything is an object. 2 is an object, “javascript is hell” is an object, 3.14 is an object, nil is an object. You don’t have to deal with primitive int vs. integer. You can actually call methods on a nil object, like checking if it’s really nil or simply lying: nil.nil? # => true

• Hashes - or what other language can call a dictionary or associative array. In Java, this would be a combination of an ArrayList and HashMaps, and would take a ton of workarounds to make it work as well as ruby does with hashes. Hashes allow you to use any object type as an index. They are awesome for representing data structures, can be nested, serialized, deserialized and can generally take a lot of abuse (not actually advised). Want to get just the keys? No problem, just call hash.keys and you’re done. Same with just values. Hash is one of my favourite things about Ruby and it will definitely spoil other languages for you.

• Collections are amazing. More specifically, what can be done with them is amazing. You can call, select, reject, collect, map, sort… anything you really need on a collection of objects to get the exact set you want, and have it transformed to your liking.

• Ruby is interpreted, not compiled. It means no wait for compilation, being able to run code on the go or in console.

Things that are worse:

• Ruby is interpreted, not compiled. This also makes it significantly slower than Java. And contrary to popular belief, Java is very fast. Take Twitter for example - at some time in the past, they had to resign from Ruby on Rails, which was their framework of choice, and move to Java, which made their performance many times faster.

• The codebase size. Java is simply much better documented, has a wider spread, and a huge codebase. The number of developers isn’t even worth comparing, since Ruby is pretty insignificant when it comes to this.

• Last time I checked, Ruby sucked to develop in on Windows. Actually, I had even tried setting it up at some point, but gave up and stayed on linux instead. Pair that up with rails and rvm, and you have a holy war going on that can be very confusing to end.

• You will miss your refactoring tools. The joys of dynamic typing, sadly, make it impossible to write refactoring tools that can even come close to Java.

Going from Java to Ruby has been quite a ride. I’d definitely recommend spending a weekend fooling around with Ruby, even if it’s just to see how meta-programming works and how fun it is to use more natural language to code. You’ll get a good brain twist trying to use the ‘unless’ statement for the first couple of hours. Oh, and also try to make your code block as short as possible, just because you can!

Other Ruby on Rails related posts from our blog.