Why we picked Ruby on Rails for our startup
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.
- 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:
- 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.
- 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
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
- 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.
- 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.