Geertjan is a DZone Zone Leader and has posted 457 posts at DZone. You can read more from them at their website. View Full User Profile

Interview: Switching from Java to Ruby

  • submit to reddit
When eSpace moved from mobile salesforce automation to web development, their confrontation with enterprise scalability had just begun. Their unique solution, and their decision to move from Java to Ruby, is the focus of the following discussion with two key players, Mohammed Ali (CTO) and Ehab ElBadry (Services Manager).

Firstly, what is eSpace?

Mohammed: "eSpace is a software company established in Alexandria, Egypt. It was founded in 2000 when eight graduates (pictured below) from the Computer Science Department at Alexandria University decided that, instead of taking the well trodden path of seeking job opportunities in multinationals, they would start their own company.

Inspired by the startup fever sweeping Silicon Valley at the time, they started their own company which has over time become a leader in the field of Web Scalability Solutions."

Ehab: "Over time, we increasingly wanted to catch the Web 2.0 wave, and we enjoyed playing with the new toys that this wave brought. In fact, we ended up finding those toys more interesting than enterprise Java, especially since they were created to support an agile model, benefiting both oursevlves and our clients. Web 2.0 further enabled us to move away from focusing mainly on work outsourced to us from the US and Europe and, instead of being the slaves of multinationals, gradually became the manager of our own projects."

The process must have been incremental. Can you describe how it unfolded?

Ehab: "Initially, we had approximately 20% Ruby projects and 80% Java projects. The 20% were mainly prototypes, not production code. It really took time and commitment for people to make the switch. The real turning point came in 2006 when, which is the largest Arabic on-line forum, became our client. (It is so large that it was even mentioned in the movie "The Kingdom", starring Jamie Foxx and others.)

The task was "simple": to renovate their forum."

What were the problems that they saddled you with?

Ehab: "Though they were the largest Arabic on-line forum, they had a very old system that broke easily. A central problem was scalaeability. In fact, they had to close membership subscriptions completely because their system  was, at some point, completely unable to grow further. That's obviously the worst thing that can happen to an on-line forum. So they not only wanted a really attractive website, but also one that would be scaleable."

Mohammed: "And all you would hear at the time was: 'Ruby doesn't scale.' That was the central challenge that we faced."

Ehab: "Not to mention the Distributed Denial of Service (DDoS) attacks."

Aside from the newness of Ruby, does it have other specific features you found attractive?

Mohammed: "Well, at the time that Ruby on Rails came out, someone out there used it to build a website for Tsunami Relief... in a matter of 10 hours. That was a very compelling situation. The Tsunami Relief site had to be scaleable, so this site ticked the right boxes for us. We also looked at the available languages at the time and at the extent to which they supported flexibility, via features such as closures and functional abilities. We needed a balance between object orientation and the power of functional features."

Ehab: "The short learning curve was a crucial factor as well."

Mohammed: "Yes, indeed. There have been huge productivity improvements for some. We had a big team on Java, working for big clients. There was a very steep curve for newbies on our team to enter our workflow. They had to learn a full Java stack, which included Hibernate and Spring. It was simply too complicated, with new employees struggling for weeks just setting up their environment. Senior colleagues had to help them with this, that, and the other, which decreased their productivity too, of course. The conceptual complexity of the full stack really weighed us down, combined with technical problems such as the stateful nature of JSF, the nightmare of configuration files, and so on."

Ehab: "Here's one concrete example: recently we were working on a web crawling project. A new developer came on board who had had a crash course in Ruby. His assignment was to redo everything the Java team had done, but in Ruby. He was done within a week, with less code, more compact, than the original.Yes, there was a performance hit, but the hit was fairly small and insignificant in the greater scheme of things."

Mohammed: "Yes, it is the bandwidth that sets you back, not the processor. Going back to a comparison between Ruby and Java, Ruby has no deep hierarchies, nor interfaces, and the dynamic creation of methods at runtime makes it extremely flexible. Today, we find ourselves making changes to libraries much more often and more easily (no recompilation!) than we did in our Java days. And introducing new libraries to old code is now simply a question of creating a new wrapper between the new library and the old code. While it is true that Java is continually evolving, with increasingly less configuration files, for example, it really belongs to the backend, as far as we are concerned."

So you are still using Java and mixing it with your Ruby frontend?

Ehab: "Definitely. For example, the Indexer is in Java. Also, the Classifier, which is the part of the code that puts a topic on into a particular category (such as "Politics" or "Science") is pure Java."

Mohammed: "Running on the same JDK allows this mixing. But, of course, if the JDK would incorporate dynamic method invocation, we'd be really happy, since it would improve the performance of dynamic languages such as Ruby."

But you also created your own unique solution, NeverBlock. Can you say something about that?

Mohammed: "Ruby has some VM performance problems, partly based on its implementation and partly based on immature libraries, in particular those related to concurrency. We have created a solution and now provide an improved I/O concurrency library to the Ruby community, called NeverBlock."

Ehab: "NeverBlock is a set of tools and utilities that allow Ruby developers to write non-blocking, concurrent code in a transparent manner, meaning that they will keep coding in their traditional ways while getting the benefit of non-blocking IO operations."

Mohammed: "Right. This is not a new API. It is a low level library that solves concurrency problems relating to sockets, network operations, and the invocation of external programs. Technically, NeverBlock builds on two main concepts: Ruby 1.9 Fibers (or Coroutines) and evented, non-blocking IO.

(More on fibers here.)

It builds on top of those to provide developers with IO access libraries that can totally hide the complexities of the evented model and add concurrency support to your applications."

So, the basic model is "fibers", rather than "threads"?

Mohammed: "Right. Fibers are "light threads" that are not scheduled by the VM, but are issued manually. They can be paused and resumed at will. Each action in the application takes place within a new fiber. One issues an action and, at I/O, the fiber pauses and then resumes at the end of I/O. There is, as a result, no scheduling overhead. There is no locking and there are no race conditions, because pause and resume both occur on demand. And, again, the user of the library doesn't need to code anything differently, only being required to configure something slightly differently."

Ehab: "It is being used in production already. Read more about our benchmarks here."

Mohammed: "Although it is not that common to have too many connections, e.g., doing I/O during ten thousands of connections, the benefits can be seen by Amazon web services, for example. When connecting to a single database, the benefits will be considerably less, since it mainly applies to scenarios where one is scaling upwards. We want to provide a fullstack solution to the Ruby community, including also something like the Python MultiProcessing library, which is utilized for running applications in multicore environments."

What concrete gains do users of now benefit from?

Ehab: "Usability. The user friendliness of Web 2.0 is obviously a boon. In addition, we've incorporated several new features, such as a statistics provider: users of the site can see how many people visited a topic. They now can also create and save drafts and there is an aggregator putting related topics into a single place."

What kind of conclusions have you been able to draw from your experiences?

Ehab: "Well, is one of the top 10 visited Ruby on Rails applications on-line today. From this and other experiences we can conclude that, firstly, we were able to create attractive and performant websites. Secondly, it is possible to create Ruby on Rails applications that scale and that are performant under load."

Mohammed: "We're now moving faster, thanks to these experiences. We're able to focus more strongly on the Gulf market, while maintaining a balance with the US and Europe. For example, we're creating a portal for the Qatar Foundation, which is a governmental entity focusing on the advancement of technology in that part of the world. Also, we're working with VodaFone and Etisalat. Recently we were at the Ruby conference to share our experiences with our migration to Ruby. (Watch it on-line here.)"

And any final comments on Java and Ruby?

Mohammed: "The question turns on the question of being dyanmic. Ruby allows that. It should be possible to have a flexbile application, one that can be changed and maintained easily. We very rarely look at Java anymore. Annotations and generics give me the creeps! They fill a space, sure, but are overused because Java needs their dynamic capabilities. But, in fact, they seem to be bending the language unpleasantly, to make it behave dynamically. When Java came out, it was a big improvement over C/C++. But, for us, Ruby has proven itself a convincing alternative in the enterprise."

fig-1.jpg30.27 KB
fig-2.png6.71 KB
fig-3.png78.59 KB
fig-4.png125.04 KB
fig-5.png49.09 KB
fig-6.png23.12 KB
Published at DZone with permission of its author, Geertjan Wielenga.


Otengi Miloskov replied on Thu, 2009/01/15 - 10:15am

Geertjan, I enjoy your articles but this one? cmon, Did you know that Ruby hype is over?!.

If I will use a scripting language it will be Groovy and Grails or better use real FP languages as Haskell, Erlang, Ocaml or Clojure those support true parallelism.

Richard Lowe replied on Thu, 2009/01/15 - 10:49am in response to: Otengi Miloskov

I agree Groovy would be the more natural choice.  Not sure when they started this project so groovy may have been a little new for them at that time but IMO Groovy has caught and passed Ruby.

Richard Rattigan replied on Thu, 2009/01/15 - 10:55am in response to: Otengi Miloskov

Not so sure about that.

Geertjan Wielenga replied on Thu, 2009/01/15 - 11:31am in response to: Otengi Miloskov

This article has nothing to do with hype. In fact, it is the exact opposite: it is the story of what real people are doing in the real world, and what their motivations are for doing so, of which there should be many more articles.

Terrell Deppe replied on Thu, 2009/01/15 - 11:42am

I wonder why they don't use JRuby.

phil swenson replied on Thu, 2009/01/15 - 12:59pm

"IMO Groovy has caught and passed Ruby"

 Groovy is more popular as a lanugage on the JVM.  But that's about it.  On every metric out there (seraches, books, conferences, newsgroup traffic, mailing list traffic, jobs available, open source projects) Ruby far surpasses Groovy.


 Where are the people whining about how this is Java Lobby and they don't want to hear about Ruby?  I'm sorely disappointed ;)


Richard Lowe replied on Thu, 2009/01/15 - 1:12pm in response to: phil swenson

"IMO Groovy has caught and passed Ruby" is from a technical perpective. Ruby had the hype machine but it is dying IMO. There is nothing you can do with Ruby on Rails you can't do and  pretty much do better with Groovy on Grails and there are more and better Java Libraries etc. Where are the people whining? alot have left javalobby and that is disappointing. 

Geertjan Wielenga replied on Thu, 2009/01/15 - 1:24pm

Anyone having a problem with a pro-Ruby article on Javalobby seems to be suggesting that the only things publishable on Javalobby are those that say "Hurray, Java rocks & everything else sucks." That, in my opinion, would create a view on the Java world that does not conform to reality. If this interview was ONLY about Ruby, sure, it should have been posted only at Ruby Zone (, but clearly this interview discusses both Java and Ruby, which therefore makes it relevant to anyone interested in Java. Plus, all the arguments mentioned in this article are based on the experiences of real developers who have actually got multiple Ruby applications in production, after having spent years with Java. (In addition, they're even contributing back to the Ruby community, which is very cool as well.) So, they should know what they're talking about. Unlike other articles I've read about Ruby, this one gets outside some lone developer's bedroom and into the real world of a company where choices are made not based only on 'what turns me on' but also on 'what makes money'. Plus plus, if you take the time to read the interview, you'll see they haven't abandoned Java at all! Has anyone noticed that? If not, read it again. They're still using Java and they're very happy with it too! That's the real world: religious wars over languages are fun but pointless when it comes to the bottom line. The bottom line means making choices that make sense in terms of making money, sustaining a company, etc., which means abandoning religious blahblah and mixing/matching whatever works best. (Pragmatism rather than its much too present cousin idealism.) Here, in this situation in this particular company, Ruby and Java are making perfect sense.

Richard Lowe replied on Thu, 2009/01/15 - 2:05pm in response to: Geertjan Wielenga

My response to the previous comment was not based on yours but his, your article as you stated does concern Java in a hetrogenious programming world good or bad and I have no problem with that. My disagreement with your article is Ruby and Java do not make prefect sense. Ruby and Java are to different skills and code thus the customer is not leveraging his workers nor his code base correctly IMO. Groovy on Grails would have given them the samething with better use of there Java skill set and current infrastructure.  Groovy isn't Java so how is that a  Java religious war?  It's his company and is welcome to do what he likes but to have a staff that uses Ruby and Java IMO is no more advantages than Perl and Java or any other language. This multiple languages for the sake of easy use will kill alot of companies just like the dot com bomb did years ago have we learned nothing?

Slim Ouertani replied on Thu, 2009/01/15 - 5:06pm

Excuse me, may be this is not a place to ask this question. but I found many people disagree about ruby and propose groovy and other languages.

This post outline some directions in enterprise and how can we switch current dev and what kind of problems we can encounter.

 Switching to groovy or new functional language may be a must now? And witch one do you want to use if you have to maintain an old java one?

For me, I said scala ;)

phil swenson replied on Thu, 2009/01/15 - 7:29pm in response to: Richard Lowe

"IMO Groovy has caught and passed Ruby" is from a technical perpective. Ruby had the hype machine but it is dying IMO. There is nothing you can do with Ruby on Rails you can't do and  pretty much do better with Groovy on Grails and there are more and better Java Libraries etc."

 I misinterpreted what you were getting at originally, but I strongly disagree with this statement.

 Ruby has a much larger, more vibrant community than Groovy.  It's kind of big enough to have a bunch of really smart people but not so big that it's overly bogged down by legacy and latecomers who want stability at all costs.

 From my perspective it's where a lot of the cutting edge stuff originates.  Most of the ideas in Groovy/Grails seem to have orginated in the Ruby community. 

And new approaches int the Ruby community continue: RSpec led the way in testing, Git is largely Ruby driven, new threading models are showing themselves in Rubinius/JRuby, RESTful behavior by convention in Rails, auto-deployment plugins in Capistrano, etc.  And Grails still doesn't have a Rake equivalent or database migrations, two of the great things about Rails.

  I like groovy and there are a few features in Groovy that I wish were in Ruby (? null check for example).  I actually use Groovy every day at work, but choose to use Ruby for side stuff as I find it more productive, more powerful, more fun, and more intuitive.

 But to each their own.

Richard Lowe replied on Thu, 2009/01/15 - 8:13pm in response to: phil swenson

  Groovy on Grails is Groovy + Java the Java libraries alone are twice the size and support of Ruby.  The reason grails doesn't have a database migration is because you don't need it it's a domain centric design and as for Capistrano, Groovy on Grails rely's on Java implementations War, Ant and Maven as well as a plugin architecture. I think I am getting cornered into bashing Ruby which is not my intent. The original intent of the post was a company used Ruby instead of Java for it's front end and Java as it's backend. Which really IMO is an outdated approach. It's not a matter of which one I like because I like Ruby but just doesn't make sense IMO to throw away a Java investment or coble together to different technologies when there is a solid answer with 2 technologies that are built to work together.

phil swenson replied on Thu, 2009/01/15 - 8:48pm in response to: Richard Lowe

gotcha, although JRuby gives you the same leverage with Java libs.  I usually don't like Java libs, the ruby/groovy ones have much nicer interfaces.  But clearly it's a huge plus to have access to the monstrous number of libs out there. 

I have huge hopes for JRuby and Groovy when the invoke dynamic bytecode is avail in Java 7.

Raphael Miranda replied on Thu, 2009/01/15 - 9:03pm

No doubt Java is too complex for 95% of all web applications out there, but jumping to RoR is too drastic.

If you're inside a java ecosystem, it makes much more sense to use Grails since it integrates much better and you don't throw out all the experience of your team in spring, hibernate, etc.

As for a rake alternative, there are several candidates as Graven, Guilder but I'd specially check out Gradle.


PS: @Richard Rattingan: It's all relative.

PS2: Can you blame people bashing ruby? This isn't rubylobby afterall.  

Richard Lowe replied on Fri, 2009/01/16 - 10:16am in response to: Slim Ouertani

If that is a good move or a bad move depends on what your doing. The answer isn't always Groovy or Multi-languages it may be just Java, Ruby or Scala. There are alot of factors not just ease of build there is maintinance, skill set, platforms supported, current investment in libs, direction of a language, uptake  etc...  Not just does this meets my need quickly I am not saying the outline post or this one is not taking that in consideration but business people get caught in the web far to often.

Umer Rasheed replied on Fri, 2009/01/16 - 5:34am

Why they are not using JRuby

Freddy Daoud replied on Fri, 2009/01/16 - 2:31pm

Geertjan, thank you for this interview/article. I found it interesting, with content much more based on facts and real-world experience than opinion and hype. It's disappointing that many people jump in and want to turn this into yet another language/framework war.

I for one wanted to show my appreciation for the content that you post. Thanks, Geertjan.


Piotr Kochanski replied on Fri, 2009/01/16 - 5:28pm

"They had to learn a full Java stack, which included Hibernate and Spring [...] new employees struggling for weeks just setting up their environment [...]". What? Weeks? Whom do you employ? Is that really so hard to download Eclipse than Hibernate and Spring and and their libraries to Eclipse Java project? Downloading JBoss or Tomcat or GlassFish does not sound so complicated too, especially when one can start/stop them right from the IDE. 

phil swenson replied on Fri, 2009/01/16 - 6:04pm in response to: Piotr Kochanski

"What? Weeks? Whom do you employ? Is that really so hard to download Eclipse than Hibernate and Spring and and their libraries to Eclipse Java project? Downloading JBoss or Tomcat or GlassFish does not sound so complicated too, especially when one can start/stop them right from the IDE. "


I've seen this sort of thing in many shops.  Many moving parts, many integrated/dependent applicaitons, complicated build processes, lack of continuous integration, long install times, complicated classpath setups, complicated source directory structures, tons of config files all contribute too it.

If you are in a shop that doesn't have these issues, you are very fortunate.

Philipp dsfgsdf replied on Sun, 2009/01/18 - 5:10pm

<cite> They had to learn a full Java stack, which included Hibernate and Spring. It was simply too complicated </cite>

What is so complicated about Hibernate and Spring? Hibernate with annotations rocks imo. I can't imagine anything nicer. And you don't need many configuration files at all. In fact, you only need one file. Ok, you can have a live and test configuration and switch between the two using a Spring configuration which is not very complicated either.

 <cite> A new developer came on board who had had a crash course in Ruby. His assignment was to redo everything the Java team had done, but in Ruby. He was done within a week, with less code, more compact, than the original. </cite>

If he was done within a week then your Java team had not achieved a lot, did it? Ruby/Groovy or even PHP may be the right solution for (very) simple tasks. And although I admit the learning curver for Java is much steeper: You are much more productive in the end.

May I give an example (it's also from a real world project): My current job is to relaunch a company's old software (financial). The current software was developed in PHP. I am developing the new software in Java (full stack = JSF, Hibernate, Spring). A few weeks ago the PHP guy had to adjust the PHP code to the new taxation rules. I did the same with the new Java code. I took 2 hours and the PHP guy took 3 days.

This is the power of the "Java full stack" when you master its complexity. You just need a few skilled developers. 




Dapeng Liu replied on Mon, 2009/01/19 - 12:12am

this thread is getting intereting ..

peronsally i don't like scripting languages, (as a result of supporting several medium sized PHP sites) 

way to ez for ppl to abuse the power of scripting languages

most of the time i can't understand what the hell the script is doing unless i actually run the code by myself 



phil swenson replied on Mon, 2009/01/19 - 11:56am in response to: Dapeng Liu

PHP != Ruby

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.