Consider Static Typing

RubyConf AU 2015

by Tom Stuart

The video titled "Consider Static Typing" features Tom Stuart speaking at RubyConf AU 2015 about the potential implications of introducing a static type system in Ruby 3.0, as suggested by Matz in his keynote. Stuart aims to unpack Matz's remarks to foster a deeper understanding and dialogue within the Ruby community regarding static typing.

Key Points Discussed:
- Ruby 3.0 and Static Typing: Matz hinted that Ruby 3.0 might incorporate static typing, which raised concerns among Ruby developers due to their unfamiliarity with static type systems common in languages like C and Java.

Three Types of Typing Proposals: Stuart explains Matz’s concepts of structural typing, implicit typing, and soft typing as nuanced approaches to static typing that seek to preserve the Ruby experience:
- Structural Typing: Focuses on the structure and methods available to an object, rather than just its class.
- Implicit Typing: Relies on type inference algorithms to deduce types without explicit annotations from the programmer.
- Soft Typing: Integrates static types with dynamic checks, potentially raising exceptions at runtime if mismatches occur.
Metadata in Type Systems: Stuart elaborates on where type metadata could reside — at the piece of source code, on values, or not at all. He discusses how Ruby currently operates with metadata on values and the implications of different type systems.
Critical Questions Raised:
- Where does the metadata go in the type system?
- What does this metadata look like?
- Who decides what types values should have?
Example Code Discussion: Stuart illustrates Matz's vision for Ruby 3.0 using example code, showing how types could be represented by the methods an object supports. This approach maintains some aspects of duck typing while aiming for more safety through types.
Challenges Ahead: While the idea of soft typing could enhance type safety, Stuart expresses doubts about its practical application within Ruby's dynamic context. He highlights the need to balance the introduction of static typing with Ruby's inherent flexibility and user-friendliness.
Future of Ruby: Emphasizing the importance of adapting to keep Ruby competitive against newer languages with robust typing systems (like Rust and Flow), Stuart encourages ongoing discussions in the Ruby community around the proposed static type system.

In conclusion, Stuart advocates for a thoughtful exploration of static typing principles that retains the essence of Ruby while advancing the language's robustness. His aim is to initiate a productive conversation within the community as Ruby evolves.

00:00:00.160 Hi everyone! Thank you so much for having me here. I'm absolutely delighted to be here.

00:00:05.359 I'm going to spend a few minutes talking to you about static typing. It's a big subject, and I can only really sketch it here, so I've written up a more detailed version of this talk on my blog. If anything I say sounds interesting, you can find out more at that URL. It will be on the last slide as well.

00:00:11.520 In November, I was at RubyConf in San Diego, where Matz used his opening keynote to talk about what might come next for Ruby. In particular, he said that Ruby 3.0 may happen in the next ten years and that it might see some new concurrency features, a just-in-time compiler, perhaps the LLVM JIT, and static typing. That's right, static typing!

00:00:30.800 A lot of people were worried when they heard that, and that's understandable because in the Ruby community we don't get much direct exposure to static type systems. They immediately make us think of languages like C and Java. So, I want to unpack Matz's remarks a little bit and provide some context and vocabulary around them in the hope of encouraging a productive conversation about static typing in Ruby.

00:01:05.439 To cut to the chase, my interpretation is that Matz was proposing three specific ideas beyond just ‘Ruby should have static typing.’ Those ideas are structural typing, implicit typing, and soft typing. These ideas provide an important degree of subtlety beyond the term 'static typing,' which would steer the language toward something very different from just Ruby that feels like Java. If you already know what these terms mean, I don't have much to tell you, but if they're new to you, I'd like to convince you that they represent interesting ideas that go beyond the features of the static type systems you might have used in the past.

00:01:43.520 As a way to get you into this subject, I'd like you to think about how computers handle values. Imagine you could crack open your laptop or your smartphone, zoom into the microscopic level, and look deep into its memory to see what was stored there. You'd see something like this: an undifferentiated soup of ones and zeros, binary data. What do those patterns of ones and zeros mean? Well, you can't tell just by looking at them; they don't have any inherent meaning, at least not an interesting one.

00:02:03.360 At the lowest level, every value inside a computer looks the same—just this pattern of ones and zeros. But when we write code to manipulate a value, we usually have a specific interpretation in mind. A given pattern of ones and zeros being used by our program might represent an unsigned or signed integer, a floating-point number, a letter of the alphabet, or the integer address of a memory location where we can find some data structure, and so on. The primitive operations inside a computer generally just assume that the values they're given are supposed to be interpreted in a particular way.

00:03:01.200 This brings us to a fundamental problem in constructing computer programs: how do we, as programmers, avoid values being accidentally misinterpreted? If we store in memory some data that represents an unsigned integer and then later retrieve that data and accidentally use it as though it represents a floating-point number or a pointer, the result of our program is going to be junk.

00:03:40.879 The type systems are a programming language technology designed to prevent this kind of error. The idea is that by incorporating a type system into a programming language, we can reduce or perhaps eliminate completely the ability of the programmer to accidentally write code that misinterprets a value. Broadly speaking, a type system is a set of rules that expect some of the things in our program to have pieces of metadata attached to them.

00:04:08.400 This brings us to the general idea: we want to take the implicit information about value representation out of the mind of the programmer and make it explicit metadata, so that it can be systematically checked for consistency with the operations used on those values. The design of type systems can get very complicated, but there are three big obvious questions to answer: first, where does the metadata go? What are the things in your program that it gets attached to? Secondly, what does the metadata look like? What information does a type tell us about how to interpret a value? And finally, where does that metadata come from? Who decides how values should be interpreted?

00:05:21.440 To answer the first question, there are three main answers that we see in the wild. The simplest possible answer is that the metadata goes nowhere; we don't have any metadata at all. This is the case for assembly language and BCPL. Programming languages that do this are usually called untyped languages, while a certain kind of person refers to them as uni-type languages. Another popular answer is that the metadata goes on values, meaning our actual in-memory representation of values includes extra information about how they should be interpreted.

00:06:32.080 This is how Ruby works. Every Ruby object begins with a structure that contains flags, allowing the programming language's operations to check it to make sure they have been given compatible arguments. Lastly, the third answer is that the metadata can be attached to pieces of source code, as exemplified by languages like C, where keywords like 'int' and 'void' declare the types of variables and functions.

00:07:40.880 So, those are the three main ways of answering the question: either there is no metadata, there is metadata on values, or there's metadata on pieces of source code. If your program misinterprets the value, a static type system can alert you to your mistake at compile time, while a dynamic one can do it during execution. An untyped language will never tell you; it will just silently produce garbage.

00:08:57.120 All else being equal, safer is better. The second big question is about what the metadata looks like, and this is independent of whether the types are static or dynamic. It’s about deciding what information we want to record regarding how to interpret values, regardless of where we record it. Most type systems you've seen are nominal ones, meaning the types are just names, such as 'int' or 'void.' However, an alternative represents that instead of types being names, they can be structures, and implicit to that idea is that you can compare types by comparing their structures and deciding whether they're compatible.

00:10:21.120 This raises a fourth question: where does that metadata come from? In statically typed languages where information must get attached to code, the most obvious answer is that the programmer provides this information by explicitly annotating the code. Alternately, we could let the computer, usually meaning the compiler, add type annotations itself through a type inference algorithm that works of pieces of information and joins it together—a process sometimes known as implicit typing.

00:11:45.840 The point of this talk is to unpack what Matz said and explore what Ruby 3.0 might look like through speculative examples of code, which Matz showcased during his keynote. He sets the variable 'a' equal to 1, commenting that the type of 'a' is integer. He also defines a method called 'foo' that requires x to have a method called ‘to’ and shows two uses of 'foo', one valid because the object passed in has a 'to' method, and the other invalid because it does not.

00:13:59.360 He states at one point that a type is represented by a set of methods, noting that you could use a class name as shorthand. Taken together, it’s clear that he’s discussing Ruby’s type system being static—beyond just dynamic metadata—and that it will use structural typing, not solely nominal typing. Instead of checking just what class an object is, the focus will be on what messages a value responds to. This preserves some of the feel of duck typing.

00:15:19.040 The real challenge lies in how to implement this implicit structural static type system while ensuring that it integrates well with Ruby’s open classes. Matz refers to a paper from 1991 describing soft typing, which attempts to apply a type inference algorithm to reconstruct static types at compile time and inserting dynamic checks where type reconstruction fails. This could assure that values are interpreted correctly by raising an exception at runtime if they're not.

00:16:17.680 While intriguing, I hold reservations about the soft typing paper since it outlines an idealized functional language that doesn't account for Ruby's complex features. It also appears to lack structurality and indeed doesn’t hold the promise of safety per se. Given that Matz emphasized the lack of need for static typing from a performance perspective, I remain unsure of what soft typing would offer Ruby.

00:17:46.080 As the Ruby community considers static typing, we face a significant challenge in bringing the safety and performance benefits to Ruby while preserving its flexibility and friendliness. Personally, I believe it's possible, and it's vital for Ruby to maintain its competitiveness over the next decade, especially as languages like Rust and Flow are rising due to enhanced static type systems.

00:19:27.360 In conclusion, I hope the insights and points I've discussed today can spur conversations within the Ruby community toward a productive exploration of static typing. Thank you very much!

RubyConf AU 2015