#backend
Oct 6, 2021

Ruby vs. PHP - which one wins?

Aleksandr Kulik
Aleksandr Kulik
Backendshowmaxphpruby
Shahadat Rahman
Ruby vs. PHP -  which one wins?

I’ve tried a lot of programming languages. I started my programming journey in university — more than 8 years ago — playing with C and C++. Later, I added Java. In the end, in what I thought it was the final change, I switched to scripting languages and started my professional career as a PHP developer. But that wasn’t the end, not by far. I accepted an invitation to a job interview and got convinced by Showmax that it was a good idea to make another change. When I accepted the offer and started working at Showmax, I changed my focus to Ruby.

At first glance, Ruby and PHP seem very similar. This is true, even though initially Ruby was a huge step forward for the whole web-development world. Now, it’s hard to find any differences. Recent changes to PHP brought a Composer and a powerful package system as an answer to Bundler and its gems. Just like Ruby, PHP became an easy-start language for web service development, and, according to multiple benchmarks, it’s actually a lot faster. So, what does the comparison look like?

Language - RUBY WINS

While syntax might be a matter of personal taste, the language design is hard to question. No matter how much better PHP is now, it still has that “bunch of different scripts not meant to be programming language” roots in its essence. Naming conventions, the order of arguments, “==” vs “===” topic, and on and on. We could probably write a book about all the things that are wrong with PHP design. Ruby, on the other hand, was initially created to be an object-oriented, easy-to-use language - and it’s succeeded.

Frameworks - RUBY WINS

While Ruby on Rails is by far the most popular framework in Ruby, it’s not that simple when it comes to PHP. Nowadays, Laravel is clearly leading in the market, with over 66k stars on GitHub. But you can make a long list of other frameworks that are widely used too, even if they aren’t as popular — Symfony, Yii, CodeIgniter, Phalcon, CakePHP, are just a few examples.

Although it might seem in line with the “pick the right tool for the job” approach, it still (mostly) comes down to personal preference. Coming to a new project often goes hand-in-hand with the need to not only learn another framework, but also the whole ecosystem around it.

Community - RUBY WINS

When it comes to the community around the particular language, things get even more complicated. The vast majority of Ruby developers are gathered around RoR. With PHP, it goes far beyond the difference in the chosen framework — communities within a community. A lot of people work with systems like Wordpress and Drupal, or commerce-oriented systems like Magento and Opencart, working on customization and development of the functionality explicitly inside those systems. And, there are a lot of people still supporting systems written in the past in pure PHP. Although more communities can mean specialization and better answers to your queries, it also means that the communities are smaller, and it can be harder to find the specific and relevant answer you need. While trying to find something, you will often come across outdated answers, and a pile of irrelevant results that include some other framework solutions or just pure PHP code.

Performance - PHP WINS

Of course, any language can be scaled. On the other hand, not every task requires high performance. But, if you want your code to run fast and you don’t want scaling to cost you a fortune, this is where PHP’s diversity of options shines. Since the release of PHP7, there has been a huge jump in performance compared to previous versions. It’s even faster with JIT in PHP8, and you can pick something like Phalcon or PHP Roadrunner for ultimate performance. While Ruby also has JIT in the new version 3, it still uses much more memory than PHP while being slower than PHP, and thus is a lot harder to scale.

The Future

Today, it’s a commonly-held belief that Ruby is either dying or already dead. The latter is definitely not true at the moment, according to the authoritative source.
The fact that some big companies are moving away from Ruby doesn’t add to the language’s popularity — there are other options, something new and fancy appears here and there, and again, PHP is not as terrible as it used to be.

So, is it really the end of an era?

Ruby still actively develops — Ruby 3 was released at the end of 2020. Rails is also actively developed and gets regular updates. Of course, it is not as hyped as it used to be, but it is still widely used and a lot of companies are in search of Ruby developers. Now’s the time to say that Ruby has become a mature tool and stopped being a fancy choice of startups, and that’s pretty much it for all the “dead” and “dying” discussion.

As for PHP, the 8th version speaks for itself. 8.1 beta in place and older versions are still actively updated, so I’d say that both languages are doing just fine.

Conclusion

It’s easy to find positives and negatives with nearly everything (well, except for the PHP language design, it might be challenging finding pros in this one). There is much more legacy code in PHP (due to significant evolution between the versions), but that also means that it’s more widely-used, and often required in job openings. Rails is not that performant, but it will save developers a lot of time because of it’s great initial design. The discussion will go on and on and on, and I don’t think there will be a clear winner — in the end, both languages solve similar tasks, so it all comes down to whether you like one language syntax over another, or you’re really used to some tool and don’t want to consider some alternatives to it. One thing I’m really sure about is that Ruby is definitely worth a try, as it won’t take you much time to dive into it, but there’s a good chance that you will fall in love with it.

Looking back, even though Ruby has it’s compromises, the transition in the opposite direction from it to PHP would be painful — it’s a simple question of joy while writing the code. Here is an example.

Let’s assume that you want to find out whether the string is a part of some other string. Well, if you are new to Ruby as I recently was, you’ll need to Google a suitable function, in this case, include?. But as soon as you know that, you are ready to go:

'hello'.include?('ello')
=> true

Wanna check an array of strings? Suit yourself:

['hello', 'ahoj', 'привет'].any? { |word| word.include?('ah') }
=> true

Need something more complex, like regexp? Ok, you will also need another function, but it’s not getting any harder than that:

'hello'.match?(/h..../)
=> true

And when it comes to PHP… well, yes, right now we have str_contains. But, as it was only introduced in the recently released 8th version, I haven’t had a chance to actually use it, which also means that every system written in any other version will use strpos.

It might not be that big of a deal to remember the order of its arguments, which seems obvious at first glance — haystack comes first, needle comes next. But it is not so obvious when you remember that there is also array_search, which has not only an underscore in its name, but also a reverse order of argument, i.e. needle first, haystack next. Even with that one function, the struggle is just beginning. It is vital to remember that the function returns both integers and booleans. Which means that you are required to use === instead of == , since the latter will prepare a very pleasant surprise when the function will return you zero (the intersection of strings was found at index #0), but PHP would take it as false.

Of course, this can be solved in multiple ways. After all, there is a whole separate function now. In the end you simply get used to it.

That’s what I did. When you work on the same problems for several years, you just stop noticing such things, as they are everywhere in the code around you. But as soon as you have a chance to try the very same things using a different method, you realize that “differently” sometimes means “better.”

Share article via: