The Benefits Of Choosing Ruby 2.0 And Ruby On Rails 4.0 For Your Project

・17 min read
The Benefits Of Choosing Ruby 2.0 And Ruby On Rails 4.0 For Your Project

I will start with a bold statement: there has never been a better time to use “Ruby on Rails”. Recently, we have witnessed two major releases of the Ruby programming language and a web development framework, which we know of as Ruby on Rails (versions 2.0 and 4.0, respectively)

However, there is always a temptation to stick with the existing versions because of the risks and fears associated with new releases. All these risks have associated costs, so project stakeholders may think that it can be too expensive to choose new releases of Ruby on Rails 4.0 and Ruby 2.0. New releases usually need “polishing”, and often contain bugs. Also, as with any new tools, the developers need to learn how to use them, and to feel comfortable with them, so as to be able to use them efficiently.  I will discuss this in more detail later in the article.I will start with a bold statement: there has never been a better time to use “Ruby on Rails”. Recently, we have witnessed two major releases of the Ruby programming language and a web development framework, which we know of as Ruby on Rails (versions 2.0 and 4.0, respectively).

Loving to use the Ruby programming language can make you a little biased towards a particular technology stack. It’s easy to go on and on about what you love doing in your everyday work: programming with Ruby. So, in order to make myself more credible, let me start by appealing to an authority. I think it is safe to assume, that the name of Jeff Atwood rings a bell with my readers. If you don’t know, he is a successful programmer, co-founder of “Stackoverflow” and a great blogger. He publically claims that he loves .NET, yet he also adds that “like any pragmatic programmer, he picks the appropriate tool for the job”.

In a previously linked blog article, he answered the question: “why Ruby”? As a very seasoned software developer and entrepreneur, Jeff obviously had to tackle the problem of “choosing the right tool for the job”, when he decided to start something new, after leaving his successful Stackoverflow project. I am glad he shared his thoughts on this matter.

So, the agenda of this article is, first to highlight Jeff’s needs and concerns, which led him eventually to pick Ruby, as the base for his next great project – Discourse.\ Secondly, I plan to do a walk-through of some fascinating changes and refinements, which come with Ruby on Rails 4.0 and Ruby 2.0.  These changes have impacted positively on the overall performance, security and quality of the products built with this aforementioned technology stack.

Finally, I will try to pull a “Jeff Atwood” and attempt to create an example list of B2B projects, where the Ruby on Rails 4.0 and Ruby 2.0 combo is a perfect fit – and I will explain why.

As a developer, with some experience under my belt, I can tell you that the savings you can make by sticking with old versions, are nothing when compared to the alternative situation where your project drifts further and further away from new software developments.  When this happens, it becomes more and more difficult (and expensive) to catch up with currently supported versions of libraries and gems. The proper attitude towards programming language / framework developments, is to treat each new version as an investment. This will not only pay off dividends in the future, but, if not undertaken, may literally stop your project at some future point of its development.

I believe Ruby on Rails, and Ruby have the best of both worlds.  Ruby on Rails has stability and maturity, which comes from having been around for seven years now. The Ruby programming language has just had it’s 20th anniversary.


When Jeff Atwood says: “Ruby isn’t cool any more. Yeah, you heard me. It’s not cool to write Ruby code any more”, what I believe Jeff Atwood is really saying is that “some established, less sexy technologies with a long track record of production and serious usage cases, may be an appropriate solution”. We should not just jump onto a technology bandwagon simply because of the hype around it.   Ruby on Rails, or Ruby itself, have not emerged “recently”. They both have a long lasting track record of real production usage.  They have proven themselves as the technology stack used to create many well known projects, such as Twitter, LinkedIn, Github and the like.

A second factor is the fast development of the framework, with new features and enhancements continually flowing in, thanks to the vibrant user community. This is something which I believe couldn’t be achieved by a more commercially based stack backed by a big company like Oracle, which stands behind Java.

As promised in my agenda, let me share some thoughts about the new and exciting features of Ruby on Rails 4.0 and Ruby 2.0. We will start with Ruby, as it’s a base and often an enabler for fantastic things you can do with Rails.

Ruby 2.0

As the release notes state, Ruby 2.0.0 is ready for practical use, and will absolutely improve your Ruby life.”  I cannot agree more, but since this statement is very general, I would like to expand on it, and point out which changes and features affect each part of that life.

Performance and stability

Changes to the Ruby core libraries in 2.0.0 include:

  • “Lazy” methods for the Enumerator and Range classes, and the “Enumerable” module that delays code evaluation until the code is actually executed. This, in itself will only result in performance improvements in some cases. Especially when elements of the enumerable will be sent through the whole chain one by one. This contrasts with the previous behaviour where “Enumerable” has been evaluating the entire enumerable at each step. However, the real benefit is that you can no longer get yourself into endless loops. Ruby is now smart some expressions it will no longer hang itself while attempting to execute the code like: range = 1..Float::INFINITYputs
  • A number of optimizations have been made to the Ruby runtime, which improve the performance. This is easily noticeable for every Ruby on Rails developer, whenever he is doing something which involves initializing the Rails environment (e.g. starting a server, running a rake command)
  • Net::HTTP performance improvements. With Ruby 2.0 each request now automatically uses gzip and deflate compression, by default. This is a cool feature which plays very nicely with the new non-GIL-blocking Zlib (more on that later). On top of that SSL sessions are also now reused, resulting in less time spent on negotiating connections.
  • Garbage collection improvements. Frankly, garbage collection was never a strong point of Ruby. For example if somebody asked me “what programming languages are suitable for game development, especially FPP shooters?”, I would put Ruby low down on the list. Despite that, I couldn’t also fend off a warm thought, that “we are getting there”, thanks to people like Narihiro Nakamura. With Ruby reaching version 2.0, we get another bunch of improvements, with the most notable being Copy-on-Write. The Copy-on-Write technique used in Ruby 2.0 allows us to reduce the memory footprint of Ruby applications forking multiple  processes (for instance Ruby on Rails application running on Unicorn).

Jeff isn’t too fond of Ruby when it comes to performance. He generally seems to be biased towards (or should I say, spoiled by?)  statically typed languages like .NET. However, he noticed that there are still a lot of low hanging fruitsto pick, when it comes to improving performance. This is something which should be easily done by the team of Rails developers. He also observed that things are generally going in the right direction.


However, in my opinion Jeff approaches the problem from the wrong perspective. Just as you shouldn’t optimize your code prematurely, the performance and scalability shouldn’t be your main concern at the beginning of your project. Sure, it is good to have a plan how to scale, but before you get to that point, there are other, more important factors impacting on your success. This is because, before your web application can emerge as a successful product / service on the Internet, it will dynamically evolve and change its shape. Consequently, your focus should be on ensuring enough flexibility and agility are embedded, in order to be able to respond to changing environments and requirements. So, dynamic languages and frameworks, like Ruby and Ruby on Rails respectively, tend to be beneficial in such circumstances. Trading flexibility for performance at the beginning of your project is not worth it.

As I have said in one of my other articles: “When you reach the point where the need for performance and scalability sufficiently outweighs the need for flexibility, you will be in a position to scale some parts of your service with, for example. Java / Erlang.   (When you grow to the size of Twitter, for example.).  I continued by saying:  The relative value of flexibility vs. performance/scalability changes throughout the lifecycle of your product / service and so does the relative strength of the technologies available. You select and modify your technology stack based on the current / changing needs of your web venture.”   So, apart from improvements in the areas of performance and stability, Ruby 2.0 has a lot to offer in terms of improving the everyday experience of the Ruby developer.

Programmers productivity and new features

  • Zlip streaming support and Multithreaded Zlib processing results in reduced memory print.
  • Default UTF-8 encoding. The errors related to encoding are, in my humble opinion one of the most grievous and frustrating to debug, that are out there. I am glad that Ruby gems like magic_encoding can be finally put to rest, since with Ruby 2.0 you can now use useful characters outside of US-ASCII, without hassle.
  • Onigmo, a new, more powerful regular expression engine. Onigmo is a forked version of the Oniguruma regexp engine used by Ruby 1.9, extended with a few more features.
  • Optimised backtrace. Backtrace does not consist of strings anymore, (though strings can be created on demand), but from a lightweight collection of Thread::Backtrace::Location objects. Therefore any code printing, rewriting or manipulating backtrace in any way should be easier and cleaner to write now.
  • Run-time debugging of production code using DTrace.

Refinements. I am sure Ruby developers will love this new way of overriding Ruby methods with the inclusion of modules. Albeit considered experimental by the Ruby team, there is a good chance that this feature will be… refined in further releases.

Other minor changes which can improve programmers productivity, like passing arguments to methods as named keywords or new syntax for creating arrays of symbols.

As you can see, a lot of good has happened with 2.0, when it comes to Ruby. Now the question is: did Ruby on Rails developers manage to keep the pace, and deliver the goods with release 4.0?  Let me try to answer that question below:

Ruby on Rails 4.0

Rails keeps up with the observable Web trend of making dynamic, responsive sites which translate to great user experiences. Ruby on Rails now arms its developers with the following handy tools and features:

  • Turbolinks. In a nutshell, the browser isn’t interpreting all the css and js each time the user interacts with the site (which usually leads to a page reload). Instead Turbolinks listens to click events, and makes appropriate requests over js and examines the response body. Then, the page is updated with data from the response. Turbolinks technique is similar to pjax, which of course Ruby on Rails 4.0 supports as well.
  • ActionController::Live basically stands for server-sent events. So far, when developers wanted to implement “publishing events” features they had to turn to libraries like Faye or create something from scratch. Ruby on Rails introduces this functionality in version 4.0, as a core function.
  • ActiveSupport::Queue. Just like with server-sent events, we finally have a built-in solution for performing background tasks. Performing tasks in the background plays an important role in creating smooth and responsive web applications. The worst thing is to have an user wait, while he is trying to use your web app or service.
  • Thread-Safety. Config.threadsafe! is enabled by default, which is a step in the right direction and better usage of, nowadays often multi core server machines.

Strong Parameters.

Ruby on Rails 4.0 introduces a new pattern for dealing with mass assigned attributes, giving a Ruby on Rails developer more control on which attributes should be permitted in a given context.

Cache Digests. Managing caches has never been so easy! Cache digest is auto included in a partial with your html code. Whenever you change the template, the digest updates and changes are automatically picked up. This plays very well with another optimisation to the way how Rails handles caches, which is:

  • Russian Doll Caching. In short Russian Doll Caching is a technique of nesting fragment caches to maximize cache hits.
  • Support for new HTML5 form input helpers.

There are also a whole lot more minor changes, bug fixes and performance improvements contributing to the overall picture, which is: developers responsible for the fourth release of Ruby on Rails did a good job. Congrats!

Having all these great features available for Ruby on Rails developers, enables new ways to develop great Ruby on Rails applications. Here is a sample list with two examples where Ruby on Rails 4.0 and Ruby 2.0 are a perfect combination:

Ruby 2.0 and Ruby on Rails 4.0 solutions:

A mature technology stack is a good choice for a mature business. When you take a look at Selleo’s portfolio, you will notice that a lot of our customers have already established, profitable businesses and are, or were looking to take their product to the next level. Their decisions, after thorough and careful thought about which technology stack to use, has been to specify Ruby on Rails. All the examples which are on my list, are custom applications, with well fitted solutions, developed independently for each of our clients.  However, all of these solutions, which made it onto my list, have something in common. The common part is the answers our clients gave us, when we asked them the “Jeff’s question”: “Why Ruby on Rails?”. Another noteworthy fact is, that two of them are specifically survey based and report generated solutions. Let me introduce them quickly:

Survey based, report generation solutions.

Metreno is a SaaS system for tests generation, sales & management, which allows our client to efficiently generate, distribute and administer HRM-related tests and surveys to their enterprise customers. The Metreno business model incorporates the idea of consultants and partner companies selling tests further into the corporate market, through a dedicated webshop module. Consultants can manage candidates/individuals and assign them to specified tests, as well as send tests to designated candidates via email.  They can view and analyse the result using the web interface. Depending on the survey module context, survey workflow can differ in minor and major details. For instance: co-workers and managers can use evaluation or video surveys, instead of classic questionnaires. Finally, the system has built-in options to generate customized reports from gathered survey data, in a form of PDF-report.


Additionally, the application has been fitted up with back-end tools for managing users, companies and transactions, including the following modules:

User/Companies Management, Subscriptions and Payment Tracking, Invoicing, PDF Report & Charts Generation, Surveys & Survey Recipients Management, Email Templates, Translations Management and numerous import/export functionalities.

ViClarity is a strategic performance and compliance management SaaS application. ViClarity is offering its enterprise clients the possibility to track and monitor performance and compliance inside their organizations. ViClarity gathers and verifies performance / compliance data, enabling real time evaluation of performance, highlighting underperforming / noncompliant parts of the system. ViClarity not only enables the ongoing monitoring of key strategic, operational or compliance objectives, but effectively drives accountability at different management levels in the organization, educating users of the system on their responsibilities.

Just as in the Metreno case, managers using ViClarity can generate a PDF-report from user inputted data, which could later be used as an important artifact.  For example, during strategic planning meetings in the organizations, where the collected data can be used for evaluating the company’s strategic direction.


Optimized workflow solutions.

The Global Sourcing Platform is SaaS B2B sourcing management online application allowing our client to efficiently conduct global sourcing projects in emerging markets. A client came to us with an already working and proven process, which involved a lot of manual work with documents and Excel spreadsheets. Our job was to effectively and efficiently translate our clients processes into the working web application, and therefore consolidate their operations of delivering sourcing projects. The result was a workflow tool designed around a master supplier database, which greatly boosted the productivity and the effectiveness of the sourcing process. We ensured secure access to the platform and a large searchable database of suppliers as well as enabling the generation and extraction of data from PDF & Excel files.

Thalamus is a SCM platform with media workflow management system. The application is a large and complex one. The main goal of the application is to support an intricate business model, which involves our client’s collaboration with B2B customers, suppliers & third-parties. Aside from reflecting our client company business workflow in the application, we have geared Thalamus with modules which allow “gathering, placing and managing orders, processing large amounts of visual material, in-house resource and supplier booking and task assignment management, quality assurance, customer preferences management”.

Why Rails?”

Some of my readers may wonder if I have made a typo, when I said that we “pulled a Jeff” and asked our clients “why Rails?”. So, when a custom software development house suggests a technology stack to the client, and the client asks: “why do you suggest this technology stack and not that”?  Our  answer is that our clients already knew that they wanted to develop their project with Ruby on Rails.  They knew it because they had already faced the limitations of other technologies.

For example a client we have built Metreno for, had several applications written in PHP, each application was for a different survey module… and of course had a different user base and management need, which stacked up with each new module (application). Maintenance, bugs, and lack of expandability forced our client to look for a new solution, in order to keep growth of his business. Ruby on Rails was a natural choice.

Another of our clients, the one who requested us to build the Thalamus platform for him, had similar problems. His old application, written in Perl, was difficult to manage and not flexible enough to answer new market needs. Simple, yet powerful Ruby on Rails features, for instance database migrations, were so much needed to naturally evolve the product, enabling it to fit into the changing market environment. The Global Sourcing Platform product owner has chosen Rails because of its flexibility and features – these are constantly flowing into the ecosystem, thanks to the thriving Ruby and Rails communities. For ViClarity, the major limitations were budget and time to market. The first constraint was overcome by the aforementioned thriving community, with its ability to create new tools and solutions, in the form of gems and libraries built and shared by the community. The second limitation has been embraced by the Ruby on Rails framework itself, where a developer is highly productive, thus not requiring so much time (and time means money).


More and more people turn to Ruby on Rails, as their tool of choice to build their next project. They do this not because of the hype, but because they see benefits coming from using a flexible and feature rich combination of Ruby on Rails framework, and the Ruby programming language. They do this because, like Jeff Atwood, they believe that choosing Ruby and Ruby on Rails is a key factor in the success of their project. Moreover, now that we have 4.0 and 2.0 releases available, there never has been a better time to pick the aforementioned technology stacks, and bring to your project the benefits of improved stability, performance and new features.

Related articles