Ruby Development Challenges: Static Typing Issues

Ruby is a language that is often called "dead". Why is it the case? Truth be told, even as a big fan of Ruby development, I understand its difficulties. When Ruby developers face “death of Ruby talk”, they’d rather not join it - but it’s not like we don’t understand its origin.

Well, there were a lot of things that happened. For example, Twitter was originally a Ruby on Rails application when it started in 2007, but after a few years, it became difficult to use Ruby when dealing with their ever-increasing users and traffic, so they turned to Java.

I've heard more and more people say "Ruby is dead" because of the migration of things like Twitter from Ruby.

Also, a Dutch company, TIOBE, publishes a monthly ranking of the most popular programming languages. It's based on the number of searches for the language on the Internet and other indicators.

It goes up and down, but when Ruby on Rails was a hot topic, Ruby was up to 8th or 7th place, but recently it's showing a negative trend.

Also, the trend changes like a pendulum between static and dynamic programming languages, but most of the programming languages of the 2010s are static.

Many of the languages that have come out recently, unlike the old days, are quite static programming languages, such as Go. For example, Go, which came out in 2009, is a statically typed language, like Swift or Rust. Then there are languages like TypeScript with types for JavaScript.

Declaring static types for things like expressions, variables, arguments, and return values, it's popular to check more types at compile time and find more errors.

In that sense, I think it's fair to say that programming languages lately have been leaning towards static typing.

Why static typed languages are favored?

The reason for this, I think, is that modern programming languages are facing a pretty big problem of scaling. As more and more things are implemented on the Web, the number of functions required of a Web application is increasing. When you start thinking, "Let's provide that function" or "Let's provide that function," the web application becomes more and more complex, and that's called scaling.

Then there is scaling in many ways, in terms of traffic or data volume, or complexity of code, or scalability in terms of the number of team members.

One way to deal with these issues is to add static types to a programming language, which has become a hot topic recently.

Static languages have dominant ways to achieve goals, standards that the entire team is constrained to follow. The initial process of learning a static language is an uphill battle but later on, it pays off.

Ruby, in that sense, is missing this particular order. Developers have many ways to solve one problem, and while it makes the process fun, the result might turn out to be unreadable. It’s harder to catch code errors and prevent tech debt.

It depends on the team

Experienced teams of Ruby developers solve this issue by imposing their own standards within the organization. If you worked with Ruby for a while, you like to know the conventional ways of doing things. Experience and careful approach allow avoiding complicated codebases - even if there are no static limitations in the language.

Still, it’s perhaps a better choice to consider Ruby and Ruby on Rails development for small and medium teams - since imposing self-made standards on the enterprise level is not the easiest task. In Syndicode, we use Ruby-based stacks for MVP development, and when working with SMBs. This is the environment that maximizes Ruby’s potential.