Sorbet vs RBS in Ruby
Introduction
Usually when we define programming languages, quite often we can read about the fact that they are divided into statically typed or dynamically typed languages.
This also applies to the Ruby language, which is said to be dynamically typed, but also strongly typed. But what exactly does this mean? It is the definition of how variables behave and interact when they are first declared. If you’ve ever faced languages like C, for example, or Java you might have seen declarations as follows
This means that we are declaring a variable that will only accept numeric values. This can be seen later when we try to assign a string to the variable, which in turn will cause an error.
In the case of Ruby, we do not declare what type our variable will be, and we could later try to assign variables of other types to the same one, therefore.
It will not cause an error, but will simply change the value of the variables to “2”.
This, of course, can be helpful in many situations, but it can also lead to problematic situations if there is something that was not considered in the beginning.
As always in this case, there is a solution that helps Ruby behave as if it is statically typed, or probably rather gradually typed. While the language itself doesn’t change, there are several static type checkers that help us define what should be used and where. While this doesn’t change Ruby to a statically typed language, it certainly helps.
One such tool is known as Sorbet. It’s a gem introduced to both normalize how methods are supposed to behave, but also so that any errors resulting from the wrong type of variables used in functions will bring us better errors.
How does it work?
Generally, Sorbet uses signatures, which show what types of variables in methods should be. They are used like this:
While signatures have started to become more than just comments on code, due to the development of Sorbet, they have become part of it and help enforce variable types.
Another way to do something similar would be RBS. RBS, unlike Sorbet, takes a different approach and stores function definitions in separate files with the extension .rbs in which we define a kind of “interfaces” for our classes or modules.
Metaprogramming & overloading
While both tools are quite useful and help you organize your work well, Ruby’s change to statically typed method definitions seems to hinder many features of the language that most Ruby programmers like. The fact that methods can be overloaded seems to be an innate feature of Ruby.
So, of course, both methods support function overloading, although both do so using different approaches.
Sorbet uses multiple sigs that are declared one below the other.
We are still left with a lot of issues related to possible problems with dynamically declared methods, or those provided by, for example, gems.
Well, both are different approaches to the same problem, and it’s worth noting that Sorbet can only be used as signatures that are next to method definitions. This obviously makes applications smaller, and easier to maintain. In case .rbi files also have to be used, then it mainly depends on preference and whether one of the methods was already used.
Summary/What does the future hold?
1. RBS: It is developed by the core Ruby team. It is a strong indication that it will stay with us for a long time and has a good chance of becoming the dominant way.
2. Sorbet: This tool, developed by the Stripe team, is certainly in pole position in the race right now, mainly because of the number of its features and the fact that it was released a little earlier than RBS. According to the developers, they have started working with the core Ruby team.
