{"url": "https://www.youtube.com/watch?v=VeoYIE370XY", "page_url": "https://www.youtube.com/watch?v=VeoYIE370XY", "title": "RubyConf AU 2014: Rescuing Ruby by Greg Brockman", "show_or_channel": "Ruby Australia", "date": "2014-02-20", "duration_s": 2248, "type": "talk", "speakers": ["Greg Brockman"], "confidence": "high", "notes": "RubyConf AU 2014 talk \"Rescuing Ruby\" (event Feb 20, 2014; uploaded 2017-05-22).", "people": ["greg-brockman"], "id": "2014-02-20_ruby-australia-rubyconf-au-2014-rescuing-ruby-by-greg", "audio_duration_s": 2247.610375, "worker": "jc-w14", "transcribe_s": 30.1, "model": "large-v3", "segments": [{"start": 11.44, "end": 38.37, "text": "So how many people here have seen DHH's Blog in 15 Minutes, the screencast about starting a blog in Rails? A lot of people. That was my first introduction to Ruby. I watched this video, and I've been doing PHP and Perl and kind of all these things, and just doing anything in those felt like there's just a lot of work, and that you're doing a lot of duplication whenever you want to start something new. And the idea that you can move that quickly."}, {"start": 38.37, "end": 62.88, "text": "That you could get started with something and just be off the ground and not have to write any boilerplate. That that was just amazing to me. And so that's really, when I think about Ruby, I think about, okay, this is something that lets you move quickly, that lets you get started, lets you get up and running. And that, you know, I think that that's really important when you think about what Stripe is, right, that we're a payment API. And a lot of what we think about is how do you make it possible for people to"}, {"start": 62.88, "end": 80.99, "text": "Get started without very much work, because ultimately, that's how you get people into your community. As developers, you're constantly seeing all this new technology and all this change. And for anything that has a barrier to entry or anything that requires work for you to get started, you're just not going to do it."}, {"start": 80.99, "end": 107.52, "text": "The thing that's been kind of unfortunate for me to watch over the years has been the fact that I think Ruby has this community behind it. It has all these people who are really excited. But over time, that niche, the set of things that Ruby is really good for, that when you think about, I've got this project, I want to get started, what do I pick? Pick Ruby. That pool isn't growing right now. And if anything, it's really shrinking. And I think that..."}, {"start": 107.52, "end": 134.03, "text": "One good example here is to think about Python. So back when Stripe was being started, we had a choice between really to start with any language. And it really came down to Python versus Ruby. And it felt like a bit of an arbitrary choice at the time, that Python seemed like it was better at systemsy things and that Ruby felt like it was better at web things. Both of them seemed like they were on this trajectory and that they were going to be immensely popular in the future. And it was kind of hard to know which one to pick."}, {"start": 134.03, "end": 162.35, "text": "And really, when you're picking a language as a company, you're not just picking it based on where it is. You're really making a bet on where you think it's going to be in five years. It's really a question of, where are the best tools going to be written? Where's the best practices and things that will allow you to actually build a sustainable system going to happen? And I think over the past couple of years, what's happened is that Python has really closed the gap there. And a lot of really awesome web libraries have happened."}, {"start": 163.15, "end": 182.11, "text": "And kind of similar story on Go. The way that things used to work would basically be that you'd go and you'd write a lot of code in Ruby. You'd write your high level language code because it's fun to write, it's easy, you can get your business logic out. And at some point you're like, man, all right, I've spent all this time trying to, just fighting with"}, {"start": 182.11, "end": 209.36, "text": "My CPU trying to get Ruby to run fast, so I'll just rewrite in C++ or a lower-level language like that. And because C++ is kind of miserable to write in, you put that off for as long as humanly possible. With Go, it's not painful anymore. It's still not as productive as a higher-level language for most applications, and so you may not want to do it for the beginning stages where you're just getting things started. But the size of an application where"}, {"start": 209.36, "end": 240.51, "text": "It finally makes sense that the lines intersect and it makes sense to rewrite in a lower level language. That size is decreasing constantly over time. And kind of similarly, when you think about just like if you're just doing pure web stuff, the place where all of the, and I guess maybe not all of it, but a lot of the new innovative stuff is happening on the web, that's all Node. You think about things like Meteor, and it's sort of not clear yet whether Meteor in particular is going to be the next Rails, but I think that"}, {"start": 240.51, "end": 268.74, "text": "That's where all the innovation is happening and all the experimentation. And you can see it in the numbers. And so here's a graph that I pulled off of moduleaccounts.com, which shows the number of gems on Ruby gems. And that's the blue line. And then the number of packages on NPM, which is Node.js' package manager. As you can see, there are a lot more Ruby gems out there. We still have the market share in terms of just because we've been around for so long and that we have so many people who have contributed."}, {"start": 268.74, "end": 300.05, "text": "But Node is rapidly growing and pretty soon we're going to be hitting that crossover point. So I think that this is something we should all be thinking about and worrying about as members of the Ruby community. I think that when people talk about making Ruby better, people tend to focus on things like the interpreter isn't fast enough. Let's just try to get a few more, squeeze a few more cycles out of things or make it a little bit more efficient or start working on jitting. But I actually think that that's"}, {"start": 300.05, "end": 330.21, "text": "Missing a lot at the point. And in reality, you know, they're also just a very small set of people who actually have strong influence over how the interpreter goes. But literally everyone in this room has strong influence over how the community goes, right? The community is just sort of the collective set of things that we do. And so I think that we all have a responsibility to think about, like, what can we do to reverse this trend, to sort of grow the set of things that Ruby's used for to make sure that we're still relevant in five to ten years. And if you think about Perl, I think that that's like a good cautionary tale."}, {"start": 330.21, "end": 357.81, "text": "At one point, Perl ran half the internet. And then it stagnated. And part of that was Perl 6, which is this language that still hasn't launched. Part of it was new languages came along, like PHP. And that started to gobble up the market share. And Perl just didn't react to it. And so in this talk, I'm going to present a bleak beginning to this. And I'm going to present at least one possible way that I think we could reverse the trend."}, {"start": 357.81, "end": 385.26, "text": "And to make sure that we make Ruby be what we want it to be. And I'm not sure that I'm right. I'm probably going to be off in places, and I'm sure that people will disagree with some of them. And I'm totally OK with that. But the thing that I really want to drive home, I think the thing that's really important, is no matter what we do, we shouldn't just sit idly by. We should start a conversation. We should be thinking about this problem. This should be something that's front and center in everything that we do."}, {"start": 385.46, "end": 412.75, "text": "And as a disclaimer, I'm going to bring up specific examples here because I think it's really important to drive home these points. I really don't want to point fingers and I think that even some of the things that I'm pointing out, those are definitely cherry-picked and might make sense in the context of the larger project that they're coming from. So anyway, in terms of what I think we should do, so I think the first thing really is let's try to expand the set of things that Ruby's used for. The set of things where"}, {"start": 412.75, "end": 441.18, "text": "When you sit down and you're like, I am working on a problem in this space, that your first thought is, I'm going to use Ruby for that. That's the thing that everyone does. And my clicker has stopped working. All right, so I think that one good way to do that is just go out there and see where is all of the rapid development happening these days? What is the thing that's getting developers excited and getting them building things? And I think that if you're strategic about it, it's actually not that hard"}, {"start": 441.18, "end": 470.86, "text": "Just go and write a library, and then people will start building on top of it just because that'll be the least path of resistance for them to do it. And so if you go on GitHub and you search for Bitcoin, I think this is a pretty illustrative example where if you look at the bottom left of this diagram, you can see a bunch of different languages and how many repos are in each one. And so Python has 420 repos, JavaScript has 415, then you get PHP and Java, and Ruby is down there at 177."}, {"start": 470.86, "end": 501.06, "text": "And so this is the kind of thing where clearly there's a ton of innovation going on in Bitcoin. There are a ton of people who are writing code who really just want to get something working. And they don't have any infrastructure yet because it's something totally new. And so this is a place where if we go and write an awesome Bitcoin library, people will start naturally using Ruby more. And so it's kind of unfortunate in the sense that BitPay just came out with this library called BitCore."}, {"start": 501.06, "end": 521.63, "text": "Which is written in Node.js. And I think that this is exactly the kind of thing that we want people writing in Ruby. And so another thing that I think is really starting to explode right now is containerization. So LXC is Linux containers. And those have really gotten good over the past couple years. And so now people are starting to explore, can we"}, {"start": 521.63, "end": 552.77, "text": "Sort of improve the way that we deploy applications, how we manage dependencies by instead of shipping around just code and then doing a build process somewhere, that we ship around built images. And so here actually, so if you search for Docker, Ruby actually has the plurality if you disregard Shell, which doesn't really count. And so, I'm not really worried about Shell taking over Ruby's market share. But the point here is, hey, it looks like we're actually in a pretty good starting point for"}, {"start": 552.77, "end": 581.65, "text": "For containerization, I could totally see a world where Ruby just becomes the default language for if you want to write anything that involves Docker, if you want to talk to the Docker API, or if you want to do interesting things there, that you just use some library that we've written and there you are. I think the second thing that would be well worth doing is to make it really easy to build service-oriented architectures in Ruby. Because the classic story that literally every single person has is that"}, {"start": 581.65, "end": 601.25, "text": "If you're building a Rails app, and really any Ruby app, you start out and you sort of build things incrementally, and you build it bigger and bigger, and at first it's great, but things run pretty quickly, and it's fine. You can go and you can look at the code, and because it's pretty small, you can hold the state of it all in your head. And then, at some point, you realize this thing is giant."}, {"start": 601.25, "end": 622.38, "text": "Whenever you make a change in one place, you end up with these cascading effects, and it's really hard to predict what's going to be affected by any particular change that you made. You look at something like Twitter, and this is exactly what happened to them. They had a monorail, and they hit this point where it was just completely unsustainable. At that point, they started breaking things out and rewriting them in Scala."}, {"start": 622.61, "end": 650.83, "text": "And it's a little unfortunate that you have to do that. The default way of building an application is one where you keep doing it until you're already in this giant hole. And then at that point, you're like, Ruby is terrible. It's causing all these problems. Let's just rewrite it in a different language. And so I think by changing the paradigm for what you do as you have a growing app and making it really easy for people to build things in the right way from the beginning, you can make sure that people are not in that hole and are able to get to a much larger size before they have to start thinking about"}, {"start": 650.83, "end": 677.01, "text": "Moving pieces into a different language. And so in terms of what service-oriented architectures actually are, so I was looking online, trying to find the least enterprising looking diagram that I could find. And unfortunately, this was it. But I actually think this diagram kind of has the key elements that I actually wanted to convey in that I think service orientation, again, this is breaking out your pieces into these different services and sort of encapsulating not just"}, {"start": 677.01, "end": 704.5, "text": "The functionality, but just in terms of if you want to understand how any particular piece of your system works, you should just have to go and look at this one code base. And it talks to these other ones, but you don't have to understand how they work. You can just look at the interface. And so some of that in terms of this platform bubble, that's just technology. You just need something that will speak thrift or HTTP, whatever you want, but will make it easy for you to have that communication. But it's also more than that. It's also this practice process people thing."}, {"start": 704.56, "end": 732.18, "text": "I just realized all those are alliterative. That is very cutesy. But the important thing there is that it's a cultural shift as well. It's this mindset shift from saying we're just going to throw code into this one code base without thinking too hard about it, which I think is totally reasonable early on when you're getting started. But as you're building something and scaling it, the challenges change. You really need to think about not just how do I move quickly today, but how do I make sure I can continue to move quickly a year from now."}, {"start": 732.62, "end": 761.44, "text": "And so one thing that we've actually done at Stripe is we've started working on something like this. So one set of tools that I've actually been working on has been taking a bunch of code that we've written internally in the process of building Stripe and breaking it out into general reusable libraries that we've namespaced under the term chalk. And so I'll be working over the next in order of six months in order to try to open source this because I think it'd be pretty useful for other people. But the way that service orientation works at Stripe right now."}, {"start": 761.44, "end": 790.35, "text": "We basically have this very simple DSL for defining. You just pass it. You can define your Thrift IDL. So this basically defines what the service interface looks like. And you pass this to your server class. You tell it what port to run on. And then you can just implement individual methods. And we have a bunch of tooling that integrates with our service discovery system. So you don't even have to think about where other services are running in terms of physical servers."}, {"start": 790.35, "end": 817.09, "text": "I think things like this that just make it very simple to do things that sort of aren't that complicated or pretty standard or don't need to be different across organizations, I think that's something that we should really be investing in as a community. And similarly, this one's a lot more specific. I think that bundler is something that we should be spending a lot more time on. I think that how much time have all of us collectively spent staring at this error message?"}, {"start": 817.09, "end": 841.65, "text": "I know that every time I get a poll at Stripe that just because of the size of our code base that someone's probably updated a gem and you're more than likely to have to run bundle install again. And I think that in reality that Bundler is actually a really great tool. I think it's actually better than any other package manager I've seen in terms of just the things that you can do with it and the problems that it solves for you."}, {"start": 841.81, "end": 869.49, "text": "But the flip side is that I think that we can't stop with sort of an 80% solution there, that we should actually be able to take this and make the user experience of actually running with the command line interface be great. And I think that little frictions like that are the kind of things that end up changing people's perception of the language in the entire ecosystem. So I think that's sort of the first section, is again just expanding the set of things that Ruby's used for."}, {"start": 869.49, "end": 899.06, "text": "I think the second thing that I propose is that we should really catch up on the things that we're behind on. And one that a lot of other languages have is just standard ways of doing very standard things. Right now in Ruby, Rails has some of this, but the thing is you can't use it outside of Rails. And that as you're building a large application, you're going to find that you're moving more and more stuff outside of Rails. Or if you're like Stripe, you won't even use Rails from the beginning. And of course there's a little bit of danger with"}, {"start": 899.06, "end": 931.81, "text": "That's the proposal that I have here in that it's very easy to say we should have standards. It's a very different thing to make sure those standards are actually adopted. And so that's something that I think we really have to watch out for. But right now, the way that these things tend to work is just people do it in a very ad hoc way. And so here's an example from an actual gem where when exception's thrown, what do you do? You just kind of puts all this stuff. And that's really bad because people are using their standard output stream for who knows what."}, {"start": 931.81, "end": 960.93, "text": "And you've just injected all these bytes into it. And so what ends up happening is when you don't have standardization, that sometimes this kind of thing will work, but sometimes you'll end up with a weird bug that's going to crop up some of the time because when there's one of those exceptions, you suddenly had these things be injected into your standard output stream, and whatever was on the other end wasn't able to parse it. And so I think that it's important both in terms of making it easier for people to write things and control things and introspect things, but also making sure that just"}, {"start": 960.93, "end": 988.08, "text": "All the pieces fit together, and that you don't have weird bugs that cause people to feel frustrated with the language. And so back to Chalk. So the way that the Chalk version of this works is that you can just include your Chalk log in a class, and then it defines a lock method. And it's very simple. And I think that this is the kind of thing that we should have. And I sort of don't really care if Chalk log in particular becomes the standard, but I think we should have something that is."}, {"start": 990.32, "end": 1019.33, "text": "Another thing I think is pretty important is that we just need to stop monkey patching language. There's been some work done for adding things called refinements. I think it was started in Ruby 2.0 and a bit of an experimental feature. My belief is that they haven't caught on too much, but I think that they're also sort of solving the wrong problem. I think that the problem with monkey patching is a few folds. One is incompatible monkey patches. There was a post by..."}, {"start": 1019.33, "end": 1047.28, "text": "I'm trying to remember, I think it was Yehuda Katz, yeah, on this great bug in Rails due to, so write AWS is the right scale gem, and it imported a monkey patch from Active Support at some point. And of course, Rails is fast moving and changing things all the time, they changed the monkey patch. And so what ended up happening is when you go to these two libraries at once, under certain conditions, you could end up"}, {"start": 1047.28, "end": 1076.35, "text": "With the monkey patch that Active Support expected to be there to be overridden by this other monkey patch. And of course, the fallout that you get, it isn't that you load these two gems together and you get an exception and you can go and fix it, but that you have this downstream effect because there's some particular controller that intended to be camelized in a certain way, and then you end up with just this very surprising exception as a result. And it's completely non-obvious what the underlying cause is. And so I think that"}, {"start": 1076.35, "end": 1105.73, "text": "That this is the character of problems with monkey patches is that over time everyone ends up with their own version of it. And that what happens is that you as a programmer, independent of where you're looking, so with refinements you at least turn it from being this globally defined thing to a locally defined thing. But still you have to understand and hold in your head exactly what the semantics of each of those monkey patches are. And to know, okay, we're sort of like using this version of Ruby effectively for this particular file. And that becomes really hard to keep track of."}, {"start": 1105.73, "end": 1132.21, "text": "Especially as you have a growing project. Another thing that I think would be really useful for Ruby is to start work on static analysis. So if you haven't used a language that has a static analyzer, has a strong static analysis ethos, then I think that this is pretty illustrative of the kind of thing that you can do. And so this is an example from Go that has this tool called Go Oracle, which is"}, {"start": 1132.21, "end": 1155.86, "text": "Basically, this magical thing where you just ask it questions about your code, and it tells you the answer. And the kind of thing that you can ask it is say, here's a function. Give me a sample call stack that invokes this function. Is this actually callable? And you run it, and it tells you. So you call this method, that method, this method, that method. And yes, this code is in fact callable."}, {"start": 1155.86, "end": 1183.62, "text": "And of course, the objection here is that Ruby is a dynamic language. You can't do full static analysis on it. Good luck, it's just like, you have theoretically hard problems there that are going to make that unsolvable. And that's totally true. However, the thing is that you can still get pretty good coverage on the code that people actually write in practice. If you have some code that a tool can't understand, a human probably is not going to be able to understand that code anyway."}, {"start": 1183.62, "end": 1210.16, "text": "So straightforward code, reasonable code, you can go and you can actually get pretty good static guarantees out of it. And so one approach that I think works pretty well is most Ruby applications are structured so that you have a load time step and then you actually have run time. So you load all the code and then at some point you invoke a main method or something like that. And that's a pretty good point at which to start doing all of your analyses. And so it's this kind of, you know,"}, {"start": 1210.16, "end": 1242.16, "text": "It's not quite real static analysis in the sense that you're not just parsing the files, but that you're sort of running some static checks over this loaded namespace. And I think an approach like that is pretty good. I have a weekend project that I played around trying to validate whether or not you could get good results over it. Ran it over the Stripe codebase, was able to find some bugs. And I think that having really good static tooling is something that can make programming language a lot more pleasant. And I think one thing that is"}, {"start": 1242.16, "end": 1271.66, "text": "Common to a lot of Ruby code is implicitness. And this is something that, thinking back to the Rails 15 minute blog post, screencast, it really, really appeals when you're getting started, that you can just move quickly, you don't have to write out all these extra symbols. And again, I think that that's reasonable for when you're getting started, but if you have anything that's growing, if you have anything that you want to be around for more than six months, that's going to come back to bite you."}, {"start": 1271.66, "end": 1295.95, "text": "And I think that what ends up happening in a lot of Ruby applications is that you go in and you realize, I can't grep this. And here's a good example from a particular Ruby gem out there where it uses method missing to sort of dynamically pull apart this method name. And does anyone, like reading this code, can anyone actually figure out what it's doing?"}, {"start": 1302.26, "end": 1330.53, "text": "I spent 10 minutes looking at this thing last night, and it took about that long to figure out mostly what it's doing. So I think the problem here is that code is really meant for humans to read. And there's a good quote from Structure and Interpretation of Computer Programs, which is a textbook, that code is meant for humans to read, and only incidentally for machines to execute. And to some extent, I feel like code is for humans to read, but only incidentally for humans to write."}, {"start": 1330.53, "end": 1360.78, "text": "You're going to have a lot more people looking at your code than people are going to be writing it. And so it becomes really important to figure out how can you write this in a way that is consumable, that people can understand what it's doing, and that it's not trying to do things in weird or clever ways. And I think that this applies in a couple layers. And one layer in particular is when you start thinking about security. So I think it's really tempting to have do-what-I-mean interfaces so that you have some thing coming into your system."}, {"start": 1360.78, "end": 1390.66, "text": "Whether you have a function interface or you have a network interface, whatever it is. But some data comes in and you can figure out by some very clever heuristics exactly what the user wants. Even though it's sort of a wide open thing. And so the place where this came up in practice was that Ruby on Rails used to allow in XML you could specify various types and it would parse it for you. And that's kind of reasonable because you probably want to serialize your higher level language constructs down to XML and pass it across the wire."}, {"start": 1390.66, "end": 1420.43, "text": "But one thing that they also added was support for embedding YAML in your XML. Now, I have no idea who would actually want to embed YAML in XML. Like, I don't actually think that there's a use case for it. But this is the kind of thing where when you think about, okay, like, it's kind of clear if the user does this what they want, right, that they have some intention, and I can kind of, you know, figure it out, even though probably no one wants it, and even though probably, like, indicates something weird is going on. And this actually was used as a vector for a remote code execution."}, {"start": 1420.43, "end": 1449.89, "text": "Because it turned out that there was a bug in how the YAML parser worked, which allowed you to instantiate arbitrary types, which if you found a type that when you instantiated it, that you run arbitrary code and you use this thing to chain it together, then at that point, it was basically game over. And so I think that both for human understandability and for security and kind of for, you know, I think that those are actually very related, right? Because ultimately what security is, it's about being able to look at your system and"}, {"start": 1449.89, "end": 1480.51, "text": "You can never be sure that there are no holes, but that's what you're inspecting for, right? That your job as a security designer is to try to go and ensure that you've thought through all of these cases. And so if you have a security hole, it's probably an indication that there's something too clever or too hard for a human to understand going on. So a related point to this is that I think that one shift we really need is to make sure that"}, {"start": 1480.51, "end": 1508.61, "text": "At each level, so whether it's you're writing a language, or you're writing a gem, or you're writing an application, that you are taking ownership of your user security. And this is something that's come up a couple times, I think. There was that mass assignment bug back two years ago where Igor Kormakov hacked GitHub. And if you're not familiar with the details there, what had happened was that there was a"}, {"start": 1508.61, "end": 1534.96, "text": "The way that mass assignment works in Rails is basically that by default you could assign to any parameter in a model, including you could override foreign references, you could override created timestamps, and clearly no one would ever really want to do that. Why would the user be able to change any of those things? It just wouldn't make sense. But it was open by default. And so Ego reported this to"}, {"start": 1534.96, "end": 1563.87, "text": "The Rails security team, and there was a big discussion about whether this is in fact something that Rails is responsible for fixing. And because at the end of the day, you can just say, this is up to the user how they want to use it. We should tell them that you should probably set these extra security flags, but it's ultimately their responsibility. And this sort of thing is a design choice, right? That you definitely can, as a library author, say, I'm going to put these red flags here, and if you use it in the wrong way, you're out of luck, that's your fault."}, {"start": 1563.87, "end": 1591.6, "text": "But I also think that's a really unfriendly way for the community to operate, and it's one that's going to lead to a lot more, in terms of a lot more security bugs, a lot more people using language in the wrong way. And a similar thing happened fairly recently with that OpenSSL had some insecure defaults on a lot of platforms, and that someone reported to the Ruby security team that, hey,"}, {"start": 1591.6, "end": 1621.28, "text": "Ruby's clients are vulnerable to the beast attack and all these other things. We should change the defaults here. And then again there was this conversation around is it up to Ruby to fix that or should it be OpenSSL's responsibility? And that there are actually good arguments there for why it should be OpenSSL's responsibility in that if you look at the track record of people messing with OpenSSL settings, that Debian at one point actually removed a source of randomness from how certs gets generated and so"}, {"start": 1621.28, "end": 1650.26, "text": "For a period of about two years, every cert on Debian was from one of about 64,000 possibilities, which was not a good state of the world. And so it is definitely very difficult to then say, hey, yes, I want to go and make these default setting changes because who knows what's going to happen over time as OpenSSL makes changes to their own library. Maybe those overrides are going to become themselves insecure. But I think, again, that"}, {"start": 1650.42, "end": 1680.19, "text": "If we choose to push these things down to different layers, if we don't take ownership over each of these pieces, that it's just going to become a lot harder for anyone to use it and that we're going to end up with a lot more problems and that I think that security is just one of those things that is so hard that you wanna make sure that sort of as few people as possible are the people who have to get things right in order to make sure that people are secure. So I've talked a little bit about what I think we should do to expand Ruby."}, {"start": 1680.19, "end": 1710.05, "text": "And the things that I think we need to catch up on. But none of those really are answers to, so why should Ruby win? Why is Ruby exciting? Why is it something that deserves to be around for the next five, 10, however many years? And I think that there is, there are a lot of elements here. And I think that some of this is a question for each of us to answer individually. But I think that Ruby does have a dynamicism and a lot of power that a lot of other languages don't."}, {"start": 1710.05, "end": 1738.45, "text": "For me personally, I think that blocks are something that, you know, they're syntactic constructs. You can do things that blocks allow you to do in other languages, but Ruby makes it so easy that it's baked into the standard library, it's baked into all of the applications people write, and you can end up writing things that are way more powerful in sort of the sense of just requiring less programmer effort or mental agility in order to get some specific thing done."}, {"start": 1738.45, "end": 1766.72, "text": "The kind of thing that I'm thinking about here, the kind of thing that I think we should all be searching for are, let's say that you could imagine writing a tool that would let you connect to your production application and let you drop into exception context, and that you could grab the state of that interpreter out and run it elsewhere, or you could gather statistics, whatever it is, that all these things, because Ruby is so dynamic, it wouldn't be that hard to write it there, and I think it would be pretty hard for a lot of other languages to replicate that."}, {"start": 1766.72, "end": 1813.01, "text": "I think that there are a lot of other possible things we could be thinking about, a lot of things we could be doing, and that that's really one way to make sure that Ruby is successful in the long term. All right, well, that's everything that I have. Thanks a lot. Are there any questions for Greg? You seem to be talking about how to ensure that Ruby wins over the long run. Why does Ruby have to win?"}, {"start": 1813.01, "end": 1841.47, "text": "Yeah, so I think that's basically my third point. And to be clear, I don't think that it has to win in the sense that I don't think that there's going to be any winner in programming languages. I think that people are going to be constantly iterating. There are going to be different spaces where different languages are going to make sense. I do think that at a couple of levels that I really want Ruby to be something that is around for the long haul though."}, {"start": 1841.47, "end": 1868.91, "text": "One is that Stripe is very invested in Ruby. We've been writing it a long time. We've been happy writing it. We'd be happy to continue writing in it, but I think that if the trend that we see continues, that would be very painful for us. But at a personal level, I think that there are a lot of really good ideas that are embedded in the Ruby language. I think it hits this balance of functional programming and..."}, {"start": 1868.91, "end": 1898.8, "text": "Imperative programming, object orientation, which I don't think I really see elsewhere. It's interesting, it has a lot of hallmarks back to Lisp and languages like that, but also does things in a very modern way. Some of it is that I think that there is a big community out there who's writing Ruby and people who are really excited about it. I think it is legitimately a fun language to program in. I think it would be sad if that went away. Do we have any other questions for Greg?"}, {"start": 1907.76, "end": 1937.89, "text": "What about things like continuing to like focusing on the things like Rails Girls and Rails Bridge and G-School and bringing, there's starting to be a real push to as a learning introductory language and growing the community and the language and because if there's more of a Ruby has more share in that space, that's another way to keep it in use and keep it growing. Yeah, yeah, I think that's a really good idea and a really good point."}, {"start": 1937.89, "end": 1980.05, "text": "Again, I think that Ruby makes it so easy to get started, and I think that's something that's incredibly valuable. To some extent, we built a company starting with the idea that it should be incredibly easy to get started, and that that's all that really matters, and I think that there's a lot of power there. Any further questions? Hi, do you think that Ruby's sort of current situation is in a part caused by the popularity"}, {"start": 1980.05, "end": 2009.73, "text": "I think that what happened was Ruby was kind of a cool new language. Ruby on Rails came out. Everyone got really excited, started doing Rails because Rails was the coolest thing that existed at the time. I think that there's always sort of this sliding scale of what cool means. Is it just the hot new thing of the day that's going to fizzle out and everyone move on to the next one? Or is it something that provides long term value and that's going to stand the test of time?"}, {"start": 2009.73, "end": 2039.62, "text": "I think Rails has in a lot of ways stood the test of time. That it's not perfect for everything, there are limitations, but I do think it's something that I think probably most people in this room would agree that has really changed the world for the better. And so to some extent I think that we need more than just Rails. I think that if Ruby remains only Rails, what's going to happen is you're going to see the next generation of web frameworks start gobbling up that market share. And that it's a new thing for Ruby, right?"}, {"start": 2039.62, "end": 2075.3, "text": "It really has been the driver of its growth, but I think that it can't be the only thing for the long haul. Do you think that part of the value of Ruby is in the, I suppose, the idiom which we write code, the things we do while we're writing code? I've been doing a bit more Python with my job, and I noticed that the way they do TDD"}, {"start": 2075.3, "end": 2101.94, "text": "Seems to be a lot different to the way we do. Do you think that's something that Ruby has inherent to it, or is that just we've been lucky that we've grown up with a TDD culture? Both. So I think that there are definitely some elements. I think whenever you're writing something, it's all about, it feels very, you've got this path through the wilderness, and you get to pick any path you want. And in reality, everyone's just gonna pick the path of least resistance."}, {"start": 2101.94, "end": 2128.85, "text": "And that for any given language that there exists a set of things that are the least resistant path, especially for like sort of if you just think incrementally and getting started. And I think that Ruby has made it really easy to do powerful things without writing much code. And so I think that as a result, we ended up with these test frameworks that made it really easy to just sort of write your tests and not really think too hard about how the framework is working or how things are structured, that sort of thing."}, {"start": 2129.52, "end": 2152.29, "text": "And in Python, you have to be a lot more explicit about things, and I think that that ends up leading to a lot more rigidity, a lot more structure, and that you end up with some sort of inversion in terms of the value there, that as something grows, that you end up with that explicitness and that structure being something that's really positive. And so I think a lot of what I'm trying to push for here is that"}, {"start": 2152.29, "end": 2190.67, "text": "I think we can keep Ruby the same at the beginning, at the small scale, but as we start to get things to be larger, we have to think harder about how they should be structured and make sure that we're being very disciplined about it. One last question for Greg. Anyone? Yep. Just on the point about the gems and node catching up really quickly, do you consider that we might have hit the critical mass on gems? And we've really covered most of the things that we need to do, so they're gonna..."}, {"start": 2190.67, "end": 2220.1, "text": "Are they going to collide at some stage and it's junk from then on in? Yeah. I actually don't think so. I think that programming in general is just so new that the surface area of things that you could cover is completely unexplored. And I do think there's something there of covering sort of all of the basic, like, we need a gem to send an email. OK, we have one of those. We don't need more of those. But I do think that there is a wide range of functionality that we're not even thinking about, or just that you see it's still"}, {"start": 2220.1, "end": 2247.61, "text": "Pretty linear in terms of the growth. So it's not that no one's writing gems anymore. It's not that this set of them has plateaued and we're hitting some asymptote. I think it's just a question of drawing more people into the community and then at that point that people will just sort of start producing gems without any real additional effort. Awesome. Greg, are you going to be sticking around for today? Yep. I'll be around for the next few hours."}]}