I always try to remember to start with the why question. Why should you be interested in learning Ruby?

Curiosity about a language is enough for some folks. Others have external reasons, perhaps you’re moving to a new project that’s Ruby based.

PHP is Not Going Away

Despite the stigma, PHP ecosystem and Laravel framework are a joy to work with. PHP packages continue to grow in number and in sophistication - thanks to modern tools like Composer and the modular nature of Symfony. Never before has it been so easy to extend an existing framework, or even create your own if you want to.

PHP as a language has improved tremendously since 5.6 into 7.0 and beyond. The 7.0 release packed several new tools into the language. The optional ability to typehint scalar values and to even typehint return values gives the power and choice to the developer to work with confidence like never before.

Thanks to Facebook’s work with the HHVM (HipHop Virtual Macine), the genius minds behind the core developers of PHP have been able to push an already performant language to a whole new territory of speed.

PHP’s unspoken motto of modularization may come from the influence of Symfony’s creator Fabien Protancer:

All I care about is the Separation of Concerns

Thanks to that vision, we have not only a framework, but a collection of loosely coupled abstractions in the Symfony. This approach is seen in other initiatives like the League of Extraordinary Packages, which doesn’t even offer an official framework, but you could easily build these solid and well tested packages together to create one.

Thanks to this take on development, it’s not required to bulldoze an entire legacy PHP application. Rather, each piece can be exchanged with Symfony components, allowing a gradual and sane approach to refactoring an application.

Ruby isn’t Going Away Either

No! Anyone saying otherwise probably has the same “be new or be gone” mentality. Just because a new language or paradigm becomes hot doesn’t mean the existing communities die.

If anything, less talent in a language or framework leads to higher salaries because real businesses rely on the infrastructure to deliver on their businesses’ promises.

I attended Rails Conference in Pittsburgh and saw firsthand the impromptu “job board” that was created at the conference. Rails remains king of the web application frameworks in the US.

Even Forbes has a hat to throw in this ring.

A Remix of a Remix of Remix

However, the concept of a package manager are not original to the PHP ecosystem. They’re remixes and interpretations from the Ruby and Python ecosystems.

And this isn’t to discredit the creators of these wonderful systems. PHP’s Composer borrowed a few ideas, but it also improved upon Ruby’s Bundler in many ways. Thanks to preplanning, we have a rich API in Composer to use it in projects that don’t even support Composer in their default state.

For instance, you can actually use Composer with WordPress leveraging the package_type field in a Composer’s package.json definition. This method options doors to install WordPress’s Plugins and Themes without uploading .zip files or using the backend to manually install extensions. You can retrofit modern day practices into applications that were built without Composer in mind whatsoever.

Saint Augustine of Hippo had this wonderful saying: “The World is a book and those who do not travel read only one page.”

It’s easy spending a lifetime within any particular language. But it’s very easy to become passive consumers of change. There are novel approaches to systematic problems in other languages and inorder to spread these changes, we need polygots.

The Value of the Polygot

As a polygot, someone fluent in multiple languages, you have the opportunity to see a bigger picture. Single -language engineers can improve the ideas created from new frameworks and packages in their ecosystem. you. We see this all of the time in PHP, there are several packages that allow you to implement OAuth and it’s abstracted well enough to support several social media logins.

However, for a non-polygot but it’s extremely diffcult to come up with completely novel concepts. Your window is narrowed to the changes in one world.

Even understanding the basics of a new language opens up doors to become a “porter”. You can identify patterns and approaches used in another language and introduce it to your primary community.

Also, in a totally different context - as a Polygot you have the opportunity to uniquely assist companies switching from PHP to Ruby on Rails. This is a common transition, but it’s difficult for both types of programmers on the team, those who are familiar with the old system and picking up Rails for the first time - and vice versa.

Your value as a team member on this type of project sky rockets, because you have an understanding of each side.

PHP has a Perception Problem

As a Laravel or even as a Symfony developer, especially if as a consultant or freelancer, you need to constantly educate your customers that Application Development is not necessarily CMS development. Sometimes you’ll even need to explain the difference between the two types of development.

From a effectiveness standpoint - it’s actually more advantageous to know PHP over any other language. At the time of writing WordPress domainates the CMS market with over 30% of the World Wide Web running WordPress in some version. This doesn’t include other noteworthy PHP CMS’s like Drupal and Joomla!

However, even though a PHP developer may go their entire career without writing a single line of code in any CMS, they are grouped with CMS developers on the surface. Every StackOverflow survey will group all PHP related statistics into one group, and I would argue that this is a overly broad generalization.

On the other hand, Ruby has one web framework that has dominated its landscape for over 10 years, and arguably brought the language itself into relevancy in the United States. Ruby on Rails is synonymous with Ruby development. There is no need to drill down into multiple catagories for this one. Ruby metrics, while not 100% always correspond with Rails activity, are much more accurate than say PHP questions that could apply to a wide range of topics - from bbPress to enterprise complex Symfony.

Learning Rails Will Earn a Higher Salary

Yes, I deliberately waited till the end to allude to this. In general, Ruby on Rails developers will earn $35,000 annually more than their respective PHP counter parts annually on average. Why? One reason is the perception problem as I was saying above, but also because of the Rails track record and the sheer size of its supporting cast of gems (gems are Ruby’s version of Composer packages).

The Ruby community is so dominated by one framework, that it’s cast of gems are going to undoubtably support one framework ubiquitously. That comes with its own sets of pros and cons.

In the PHP ecosystem, you can easily plug in and play several different agnostic ORMs. From Doctrine to Propel, to lesser known packages. But in Rails, even the Data Mapper pattern powered ORM known as DataMapper has largely gone wayside to its ActiveRecord counterpart.

Learning Rails will narrow your vision in certain aspects. Venturing outside of the Rails built-in opinions is inherently against the philosophy of the framework. That’s what makes it so productive out of the box.

Because of this productivity, and the quality of the lanuage, you’ll find yourself in a zen-like state of flow at times. Laravel has this same power and philosphy behind it, but ultimately has to play catch up to the king of RAD.