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.
