What If... ?: Ruby 3

by Eric Weinstein

In his talk titled "What If... ?: Ruby 3," presented at RubyConf 2017, Eric Weinstein explores speculative scenarios around the future evolution of the Ruby programming language. Utilizing the narrative style inspired by Marvel's "What If?" comics, Weinstein discusses three hypothetical situations to envision alternative paths Ruby could have taken or might take in the future.

Key points from the talk include:
- Static Type System: Weinstein questions what Ruby would be like if it had a static type system, contrasting it with its current dynamic type system. He outlines that static typing could catch errors at compile time, enhancing safety but sacrificing Ruby's flexibility and metaprogramming capabilities. He references the language Crystal as a statically typed alternative to Ruby, which sacrifices some of Ruby's dynamic features for speed and type safety.
- Running in the Browser: The potential for Ruby to run natively in web browsers is explored. Weinstein mentions Opal, a Ruby-to-JavaScript compiler, and discusses the advantages and disadvantages of compiling Ruby directly to JavaScript versus WebAssembly. He raises questions about usability and the challenges that would arise from such a shift in environment.
- Global Interpreter Lock (GIL): The talk concludes by addressing the implications of Ruby’s Global Interpreter Lock on concurrency. Weinstein discusses how eliminating the GIL could lead to more effective parallelism through new concurrency models, such as actors and guilds, which would encourage safer interaction between threads without the use of locks.

Overall, Weinstein emphasizes that the future of Ruby could incorporate gradual typing, enhance its concurrency model, and possibly see it utilized in web environments. He invites the Ruby community to engage in discussions around these possibilities, encouraging innovative thinking about Ruby's trajectory.

00:00:10.670 So, I think we'll go ahead and start. First, thank you so much for coming! I really appreciate your choosing to spend your time here with me and attending my talk. There are a bunch of fantastic talks going on, so thanks for choosing this one. I also want to thank RubyConf, our sponsors, the venue, and New Orleans. Thanks to everyone who helped make another RubyConf possible.

00:00:34.739 As always, I’m super delighted to be here, and I'm thrilled to have you here. I apologize that I can't really see any of you; it is unbelievably bright up here. But you'll see in a minute why I do need at least some of you to be visible.

00:00:41.149 This talk is called "What If Ruby 3?" but it’s also known as the "Future of Ruby, Part 3." This is designed after one of Justin's slides, and it’s the third part of a three-part talk track on the future of Ruby. We've sort of seen the past and some apocalyptic visions of the present, and now we’re going to talk a little bit about what Ruby could have been like, or what it still might be like. We’re going to do things a little differently than I normally do talks.

00:01:13.080 I typically rely very heavily on presenter notes, and I often inadvertently read rather than talk to you. So on Justin Searle's advice, I’m foregoing presenter notes entirely, and we’ll see how that goes. Also, if at any point I start trailing off or lose my space, please start applauding; that would be really helpful for me. It’ll give me a moment to reorient.

00:01:39.689 I'm delighted not only to be friends with Justin but also to be a client. What that means is Justin now has to take me out to fancy dinners! So anyway, this is a computer talk, and that means you have to start with zero. Hello, my name is Eric. I tend to speak very quickly, particularly when I get excited.

00:02:20.070 I find discussing Ruby and the future possibilities of Ruby and the community really exciting. So if, at any point, I start to go off the rails and speak way too fast, this is why I kind of need to see some of you, especially those of you closer to me in the front. If you could do something to give me a sense of ease, it would be great. I will talk for about 35 to 40 minutes, and if we come close to 2:35, we'll have a couple of minutes for questions. If we come closer to 40, then I won’t have time for questions.

00:02:53.340 But please feel free to stop me after and ask any questions, or we can chat about anything you would like. So, like I said, my name is Eric Weinstein. I am a Director of Engineering at Fox Networks Group in Los Angeles. We're currently building a platform and a team around our television content API, which includes shows like The Simpsons, Archer, National Geographic, Fox Sports, and more.

00:03:10.860 We are hiring, so please feel free to ask me about that as well. All my information is in this human hash I felt compelled to make. I read a lot of JavaScript and Node at work, but I write Ruby in my—well, not as much free time as I would like. I've been writing Ruby for several years now and I recently wrote a book called Ruby Wizardry.

00:03:54.030 I’ve been saying recently, but I guess it's not so recent now; it's about three years old, which means we’re due for an update. There’s a 30% off promo code, RUBYCONF30, that you can use at No Starch Press’s website for the book. If you're interested, please go ahead and take advantage of that. Thanks to the folks at No Starch for setting that up.

00:04:07.739 The book teaches Ruby to eight- to twelve-year-olds, but if you have any questions about that, please come find me after the show. This is not a long talk, but I believe we benefit from having a roadmap. I’m going to start by talking a little bit about Marvel's What If comics, then discuss the power of narrative and meta-narrative, and finally look at some of the possible futures of Ruby through three What If stories.

00:04:27.290 What if Ruby had a static type system? What if Ruby ran in the browser? And what if Ruby did not have a global VM lock? So, like I said, I’ll do my best not to read to you. Small classes, small methods, and small slides.

00:04:39.660 The meta-narrative component, which you’ll see in a minute, is entertaining and not like Clint Eastwood yelling at an empty chair. So... What If? If you’re not familiar, the What If comic line from Marvel has done two separate runs—basically, non-canonical stories about the Marvel Universe featuring questions like: What if the X-Men had been founded by Professor X and Magneto together? What if Jessica Jones had joined the Avengers? What if the Avengers defeated everyone? I feel like this question is maybe not the most interesting, but I would definitely read that comic book! So basically, these comics explore what if things were different than they are now, all while considering the rules of the universe.

00:06:06.240 What if the history and potential futures were different? The question of "What if" is a powerful one, deserving powerful music. I had wanted to use Marvel's fanfare, but then I remembered this talk will be on YouTube, and I didn't want Marvel to yell at me. So I picked a different music. I'm going to play that one more time just to see how it fits.

00:06:44.760 Does anyone happen to know what that is? I apologize for not being able to see you; I can't tell if hands are raised, so just feel free to shout if you know. If you don’t, it is actually the theme from the Bloops of One project by Why the Lucky Stiff. There’s been a lot of good content today about the history of Ruby and our community, and Why was a very big part of that.

00:07:06.580 His projects have been a big part of it, so I’m delighted to share a little bit of his content. If you have questions about Why, I’ve never met him, but I've studied him. Or if you have questions about how things used to be, or Bloops of One—or whatever, please come find me or another grumpy old person.

00:07:36.600 Ruby 3 aims to be three times faster than Ruby 2, according to Matz. I do think we will get there, but there’s also the question of what else we will gain. We saw there will be some new features in Ruby 2.5—every Christmas, we get a new version of Ruby, and it’s exciting to think about what could ship in Ruby 3.

00:08:00.460 As I mentioned, we have these three What If scenarios focused on types, Ruby's execution environment, and its concurrency model. I think they could be really interesting, and it’s possible people will look back on this talk and say it was truly the beginning of Ruby 3.

00:08:29.300 Good! I’m glad this part works. Feel free to read that in Ron Howard's voice if it helps you. Thank you for laughing! Also, if this seems a little new and weird and strange—because this is going to be Ruby that doesn't quite look like Ruby—feel free to think of it as a different programming language.

00:08:44.130 I don't know how many of you know this, but back in the day when Matz was selecting the name for Ruby, he narrowed it down to two names, and the other name was Coral. So, if you want to pretend you're at CoralCon for the next 33 minutes, please do!

00:09:04.730 Let’s start by talking about Ruby's type system and exploring the idea of what if Ruby had a static type system. Static and dynamic type systems differ in crucial ways.

00:09:30.140 In a static type system, all variable types are known at compile time. For instance, whether you have a fixed number, a string, or a symbol, when you compile it, you know that you're not going to encounter something that doesn't respond to a particular method at runtime, because you know the type and its methods.

00:10:07.320 This may or may not make use of type inference. If you've written a lot of Java, you know you're constantly indicating what type everything is. If you've written Go, then you realize you have a powerful type system that doesn't require you to specify the type; sometimes the compiler will understand what you mean.

00:10:36.990 In contrast, dynamic type systems do not have known variable types until runtime. This means that you can encounter an error if you call a method on it that is invalid, such as trying to add two incompatible things together. There's also a discussion about weak versus strong typing.

00:11:00.700 This distinction may be contentious, especially regarding static and dynamic typing; I beg you not to add me about this. For the purposes of this discussion, weak typing means it does not silently do the wrong thing instead of throwing an error, while strong typing throws an error instead of performing an invalid operation.

00:11:24.190 In this vein, Ruby is strongly and dynamically typed. To better understand Ruby’s types, I’ll provide a quick crash course through YARV (Yet Another Ruby VM), the VM that modern Ruby uses.

00:12:03.830 The steps are broadly speaking tokenizing and lexing—picking apart a string of code to figure out what pieces are in it—parsing it to understand grammar, compiling it to bytecode, and then executing. When you write something like ten.times do, you're essentially converting human language into machine language.

00:12:41.170 I apologize if this is hard to read, but at the top, we have ten.times do n, which outputs the numbers one through ten. Note the result of calling the lexing method involves tokenization and metadata associated with the items. For instance, Ripper is a tool that comes with Ruby to dissect your Ruby code and reveal its inner workings.

00:13:18.620 YARV processes commands, and if you want to see what the parser is doing, you can use the '-y' flag when running the interpreter on a Ruby file. Both examples have been well documented in Pat Shaughnessy’s book, "Ruby Under a Microscope. " If you haven't read it, I highly recommend it.

00:13:56.670 Thus, we can examine the bytecode of Ruby using RubyVM::InstructionSequence.new to compile our code and then call 'disassemble' on that execution. Again, I apologize if this is hard to read, but you’ll see a series of instructions from the bytecode.

00:14:29.250 The crucial takeaway here is that Ruby is not statically typed. So there’s effectively nothing preventing you from calling a method on something that doesn’t respond to it at runtime. Things will fail at runtime, and there are ways to rectify this.

00:14:57.100 For instance, consider the programming language Crystal. Traditionally, it has a logo that might be enigmatic. Crystal is similar to Ruby syntactically but is statically typed. Its tagline proclaims: "If Ruby was fast, Crystal is faster!" You can both write similar code in both languages.

00:15:21.670 In Crystal, you often have to tell the compiler exactly what you mean regarding types. This code will compile in both Ruby and Crystal, although the visual representation differs, as Crystal's type system infers types statically. If you write a Ruby program that depicts basic functionality, it could run meaningfully in both environments.

00:15:53.630 So if we wanted to make Ruby statically typed, we would need to sacrifice some metaprogramming magic and rapid prototyping benefits. This trade-off could be very engaging to explore since having stronger static types can catch many errors at compile time. Also, it might depend on whether you're seeking programmer speed or execution speed.

00:16:28.390 If Matz talked about good changes and bad changes this morning, the question is really about trade-offs. If we continue with dynamic typing, we trade execution speed for flexibility and risk losing some metaprogramming magic. Conversely, if we opt for static typing, we maintain speed at the cost of flexibility and some programmer convenience.

00:17:09.540 In the case of dependent typing, like that of Idris, it’s entirely possible to trade flexibility for strong compile-time checks. It opens the question: is this a good idea or a bad one for Ruby?

00:17:28.540 I suspect something akin to gradual typing could likely become integrated into Ruby's future versions. Now, pivoting aside from type systems—what if Ruby were to run in the browser?

00:17:46.930 For those who don’t remember, this is Netscape Navigator, a representation of what the internet used to look like—and in some places still does, particularly in the about.me pages of computer science professors everywhere. Imagine if Ruby could run in the browser; that would be amazing! We could pop open the console and not have to engage in hacky editing.

00:18:17.470 For those unfamiliar, using personal w, we would receive an array of strings: "one, two, three." We call 'map' and indicate that we want all of those to become integers, and then integers return back. However, those who have tried writing JavaScript understand a much different outcome.

00:18:40.240 What happens is that, even if you think you are performing an action, JavaScript alters function arguments based on the structure. If a method requires two arguments but you pass only one, it reads and uses the method index as the second, which leads to unexpected outputs.

00:19:03.090 After a bit of debugging, you might discover that you have to resort to passing an anonymous function to achieve the desired behavior. This is the landscape of JavaScript, so why isn’t Ruby in the browser? Technically, it does, sort of. If you haven’t encountered it, this is Opal.

00:19:24.700 Opal is a source-to-source compiler for JavaScript that converts Ruby to JavaScript and executes it in the browser. Do we envision a world where tools like Opal enable us to write Ruby without engaging with JavaScript? Would we be happier if we used Ruby directly in the browser?

00:19:46.260 Or wouldn't we find ourselves complaining about Ruby the same way we do about JavaScript? Would we question the dynamic typing of Ruby? What difference would Ruby's design make if it were meant to handle HTML and be an asynchronous-first language? Additionally, consider how different Ruby’s concurrency primitives would be if it had to operate in a browser environment.

00:20:17.980 If you're curious about this, we can chat later about an interesting talk called "The Birth and Death of JavaScript" by Gary Barnhart. This talk traces the history of JavaScript and speculates on future possibilities, including the evolution of JavaScript.

00:20:47.430 This leads us into discussing the WebAssembly project, which is roughly two years old. WebAssembly serves as a middle ground where we have a browser-compatible assembly-like language that other programming languages can target.

00:21:10.650 This perspective raises the possibility that Ruby could come in a form that allows you to compile to WebAssembly, isolating ourselves from JavaScript complications.

00:21:34.020 Yet, how beneficial is compiling Ruby to JavaScript? Consider it might be the worst of both worlds where we do have to engage with JavaScript and figure out debugging Ruby-to-JS compiled code.

00:21:56.870 Alternatively, we can mitigate the JavaScript headaches by compiling directly to WebAssembly, although we'd still face the wild west environment of the browser. Additional considerations come into play when we reflect on using WebAssembly.

00:22:17.830 In terms of server-side control, we maintain dominance over the environment, but sacrificing Ruby for WebAssembly may make it necessary to learn new environments. Additionally, there's a rather interesting gap between Ruby and JavaScript that could complicate matters.

00:22:38.880 Now let's turn to the final scenario: what if Ruby had no global interpreter lock? I called this segment "What if Ruby had no GIL?" but it's more accurately framed in terms of altering Ruby's concurrency story.

00:23:00.400 The Global Interpreter Lock, or GIL, is a mutual exclusion lock that allows only one thread to execute Ruby code at any given time. The concept is somewhat like a talking stick—when one thread has it, no other threads can execute.

00:23:23.790 Historically, Ruby has struggled with concurrency, leading it to implement the GIL to alleviate race conditions and data corruption risks.

00:23:46.320 As noted previously, not all Ruby interpreters have the GIL; for example, JRuby does not. Other scripting languages, including Python, have a similar lock protecting from the chaos of multithreaded access.

00:24:12.590 The GIL is designed to avoid race conditions. Yet we can consider pulling the GIL out of Ruby entirely and explore different concurrency primitives. Individual threads can exist without sharing mutable state, and this becomes crucial when reviewing Ruby's concurrency problem.

00:24:39.840 The takeaway here is that concurrency is about doing one thing at a time, while splitting tasks among multiple threads or processes can lead to genuine parallelism using cores or separate machines.

00:25:05.380 Concurrency in this sense is difficult because you can only run so many things at once when sharing access to mutable state. The challenge is to determine how to structure these avenues within potential solutions.

00:25:32.210 Among notable concepts is that of guilds, which separates what can happen safely in parallel from what cannot. With this model, it becomes easier to manage shared mutable states.

00:26:02.570 You could create a new guild that runs separately, enabling better parallel execution. This references a larger concept within Matz's vision of the future of Ruby.

00:26:29.360 Additionally, Matz hinted at enhancing concurrency abstractions via actors. An actor model allows simple communication through message-passing rather than actively engaging locks, essentially eliminating much mental overhead.

00:26:50.740 The paradigm reveals that actors only operate on their own states without interference from others. This conversation invites parallels from Rust and its ownership interactions, which share similarities in our understanding of state management.

00:27:14.630 We would likely reach a Ruby iteration where we could implement guilds, actors, or effective concurrency primitives without reliance on complex locking mechanisms.

00:27:35.610 This raises questions about how to secure safe and productive environments for Ruby's new concurrency. As we glance toward potential implementations, it’s essential for us to engage broadly across the Ruby community.

00:28:02.560 This brings us to our TL;DR segment. If you missed any key points, here's your recap! Asking about different systems of typing can yield numerous possibilities. While static and gradual types might be incorporated into Ruby's framework, the future remains far from definite.

00:28:29.330 We must consider the motive to encapsulate Ruby's ecosystem within the WebAssembly environment. Parallelism, and introducing new concurrency primitives, can place Ruby at the forefront of programming languages.

00:29:01.390 Thank you so much for your attention and engagement throughout my talk. I genuinely appreciate your presence and support.