Strong Dynamic Typing

It's crucial to grasp that Ruby employs strong dynamic typing. To illustrate this concept, consider the following example:

text = "hello world" + 10

This code will trigger an error:

no implicit conversion of Integer into String (TypeError)

This demonstrates that Ruby prevents the mixing of different data types, unlike languages such as JavaScript, where results can be unpredictable. This built-in type safety helps minimize errors and unexpected outcomes.

Conventions in Ruby on Rails

A key tenet of the Rails framework is "Conventions over configurations." This principle has been embraced by the community for years. The flexibility of dynamic typing allows for various implementations, yet developers tend to adhere to established conventions, leading to standardized code across projects.

As you explore different Rails applications, you will notice a consistent code structure and architecture. For example:

def even?(number)

number % 2 == 0

end

This simple function illustrates several important principles. The question mark at the end signifies that the return value is boolean. While naming the function is_even(number) is possible, it's rarely done in practice. Moreover, the parameter name implicitly conveys its type, with developers opting for meaningful names.

Challenges with Large Projects

As a project expands, challenges can arise, particularly regarding type understanding. For instance, consider the following code snippet:

class PaymentService

def process(order)

...

return receipt

end

end

While the code appears straightforward, navigating a large codebase with numerous classes and modules can become complex. Questions such as, "What type is the order argument?" or "What type does receipt hold?" can lead to confusion, especially when similarly named classes exist in different namespaces, such as Customer::Order and History::Order.

Thankfully, there is a remedy. The Sorbet project was developed to assist with type checking in Ruby.

# typed: true

class PaymentService

extend T::Sig

sig { params(order: Customer::Order).returns(History::Receipt) }

def process(order)

...

return receipt

end

end

In this updated class, we add extend T::Sig to enable type checking, along with the comment # typed: true at the top of the file. Additionally, we include a signature right before the process method, specifying the types of the parameters and the return value. This enhancement greatly aids developers who are unfamiliar with the code, allowing them to understand the data types involved.

If a mismatched type is passed or an incorrect number of parameters is provided, an error will be raised:

Expected Customer::Order but found History::Order for argument order

Sorbet also provides null safety. If a potentially null argument is passed, it will issue a warning. To recognize nullable types, a wrapper T.nilable() is required.

While new approaches often face criticism, some conservative developers argue that Sorbet complicates the code and detracts from Ruby's natural elegance. However, numerous presentations from Stripe have indicated that integrating Sorbet significantly reduces bugs and enhances developer satisfaction.

In conclusion, Ruby's dynamic typing can be daunting for many developers. They may attempt to use it and feel a lack of control over the code. However, type management in Ruby is evolving, particularly with the advent of Sorbet, which provides improved clarity and safety around data types.