Why we picked Ruby on Rails for our startup

Victor Liew
Xfers Engineering
Published in
4 min readJun 26, 2019

--

To understand the reason for picking Ruby on Rails, we have to turn back time and look at the tech scene in 2012, the era of iPhone 5 / Samsung Galaxy S3.

In 2012,

  • Java, Javascript, Python, PHP, and Ruby took the lead in having the largest developer community
  • GoLang was only 3 years old
  • TypeScript was just introduced
  • C# and the .NET framework was pretty good, but you had to pay an expensive licensing fee for a Microsoft IIS Server to host it

The natural choice back then was to pick from one of the 5 most popular language* that has a good developer community, 3rd party libraries and stability.

This leaves us with the following choices and some of the considerations that come along with it:

  1. PHP started off as a templating language for HTML. If you were building web applications during that period, chances are your toolkit of choice was PHP. Its scripting / templating nature creates a lot of bad programming paradigm out there and the ease of picking up this language was a double-edged sword. An average beginner could learn PHP in a day and will tend to make a lot of mistakes while working with it. If your team consists of a group of beginner engineers still in college (which we were), chances are you will find yourself with a lot of strange bugs that crop out every now and then that are extremely hard to catch. Things might have been different if PHP 7.2 existed then and we were all experienced PHP developers.
  2. Java was a typed language. If you had started learning web programming from a PHP / JavaScript world, Java was pretty overwhelming to pick up. Web frameworks that accompanied it were mostly Java Server Faces (JSF), Struts and Spring framework. If you had any experience developing in them, you will realize that the speed of development was extremely slow, along with a steep learning curve. It doesn’t help that Java itself is a language that is pretty difficult to pick up. (There was PLAY framework as well which was considered easier to use, but it wasn’t mature enough back then with a good developer community)
  3. JavaScript on Node.js was still in the early stages of development. We felt like it needed more time to be mature. Additionally, Node.JS support for Windows was only released in July 2011. Why is this important? Mac was extremely expensive for an average college kid then. The need to dual boot your laptop creates additional friction and prevented it from gaining popularity for developers to give it a try.
  4. Python VS Ruby — It boils down to choosing between a python or ruby stack at the end of the day. For an in-depth comparison and discussion, this article sums it up pretty nicely.

In the end, we picked Ruby on Rails due to the following philosophy which we felt were important:

Strong TDD philosophy

Our first commit back in Jul 2012. Testing comes out of the box!

No multiple-inheritance

Deciding on a basic Single/multi-level inheritance is tricky enough if you want to adhere to a good inheritance design pattern. Avoiding the diamond problem will be difficult if you are blending both multi-level and multiple inheritances in your codebase.

In Ruby, we favour composition over inheritance by using mixins, even though the drawbacks might consist of making the behaviour of the system harder to understand, and methods that exist in a class may have to be re-implemented in another class (or extra efforts is required to convert that method into a mixin)

Strong + dynamically typed

  1. A strongly typed language makes a language more predictable, earlier detection of errors and hence resulting in fewer side effects. The loss of some flexibility with more predictability is beneficial over the long run.
  2. Dynamically typed languages are way easier to read. Period. (Of course, we can always choose to add in static typing later if we want to increase predictability )

*C++ / C wasn’t in the list, as there weren’t any good web frameworks that were available then. Pointer management was pretty much a manual process and the speed of iteration required to build web applications made it unsuitable.

--

--