[0:00:05] So Greg, you're, I mean, by way of introduction, you're the CTO of Stripe. And so obviously come from a bit of an engineering background and a fairly deep Ruby background as well. Yep, so I joined Stripe back when we were four people. So that was late 2010. And the first thing I did was I built out all of the infrastructure and figured out how we were going to actually scale the API.
[0:00:35] Stripe is primarily a Ruby shop and I've written lots of Ruby at various levels of the stack in order to, again, sort of figure out how to build a company like Stripe and how to make it operate at scale as we're growing to the scale we are today. So one of the criticisms that often comes of Ruby is that it doesn't scale. Now...
[0:01:03] To what extent have you found that to be true, and to what extent have you found that to be something which is a little bit of a fun thing to say and not really true? So scaling means a lot of things, and there are a lot of components to scaling. And I think what a lot of people focus on is just performance, right? You look at CPU time, and you compare that across different languages, and you say, okay, whatever thing is going to consume the least CPU is the thing that's the most scalable. In reality, it's much more nuanced than that.
[0:01:33] The thing that's most important is as your company grows, as your code base grows, as the amount of just stuff that you do grows in scope, how does your overall impact, your overall ability to get things done, when you sort of aggregate together the amount of time you're spending building new stuff, maintaining existing stuff, and trying to debug problems, which of these is going to be the one that will most advance your project or your company?
[0:02:01] I think that there are clear issues that everyone sort of acknowledges with Ruby on the CPU basis, and that people have been working on making the interpreter faster, but that a lot of the issues that we've identified as Stripe has scaled have been ones that aren't just related to that, right? It's easy enough to take a bottleneck, rewrite it in a different language, and call it good. The thing that's a lot harder is, okay, I have a lot of code, now it takes 10 seconds for my application to load, maybe I can improve that, but...
[0:02:30] In reality, the important question is more, okay, can I still figure out where any line of code is, or any individual method is defined easily? Can I be sure that if I make a change in one place, it's not going to affect others? Can I be certain that... How much code do I have to grok in order to make any local change? Things like that. And so I think one thing that happens as Ruby code bases grow is that...
[0:02:57] The default conventions just don't work anymore. That you end up with this surface area that sort of encompasses all of the code rather than any individual module or piece of it. And so what ends up happening is that your development has to slow down if you're just building it in the naive way. And sort of on the other side, that if you approach it from the right perspective, if you approach it from not letting yourself get any one
[0:03:27] I think it is a mistake once you're about a certain size to try to stay entirely in one language, no matter what that language is. You'll often find that for particular applications, you understand very well that...
[0:03:53] It will make sense to be written in a language that is most appropriate for that domain. But at the same time, you want to make sure that the complexity of your systems don't spiral out of control. And so the short answer to does Ruby scale? The answer is not if you're being naive about it, and I think that's probably true of any language, but I think that there are a lot of sharp edges with Ruby that a lot of people aren't aware of. And that's one thing that I want to talk about in my RubyConf keynote.
[0:04:22] How much would you say some of the naivety has come from people being introduced to Ruby through Rails and treating them as equivalent? I actually think that that's a very interesting point and a good question. If you think about PHP, I think everyone has
[0:04:44] I think that the way that people onboard into the PHP community is that you start out with this very easy to get started thing, and then you kind of keep iterating from there. And if you look at a typical PHP project, it's going to be something that's going to be just a mess of code, and that no one's really going to understand the entirety of it, and you just sort of make changes and you kind of hope that it's not going to break anything too much. And I think that Ruby is, it's not quite as easy to get started with as PHP, sort of nothing is in the PHP.
[0:05:12] Sort of the simplest PHP app is just an HTML page, right? And that that's something that I think is like really well, that's actually I think really nice thing about PHP is how easy it makes people get started. But I think that the responsibility then is on the flip side where, okay, once people are sophisticated and understand more of what they're doing, are they able to write things in a more sophisticated way? Are there good examples for them to go and copy from and learn from?
[0:05:39] I think that with Ruby on Rails is kind of a similar story where getting started is really easy. You have all these generators that you go and you use those that you can kind of copy and paste a lot of code off the internet and that's easy to get started. But the problem is that there aren't good examples of high quality code out there. It's not easy to come across conventions or styles that you should be copying and that a lot of the standard patterns of Ruby on Rails
[0:06:06] That make it really easy for you to get started are also patterns which, as you have a larger and larger code base, start to make it very unmaintainable. I was talking to Ben Smith the other day in an interview where he was talking about some of the patterns for architecting a Rails app to be scalable from the ground up. And there are obviously things that we're not teaching to all the people who are onboarding through all of these.
[0:06:33] Code schools and stuff, we're teaching them to build their first blog. Yep, and I think importantly, Ruby is larger than Rails, and I think this is something that people don't talk about as much as they should, and that Ruby on Rails is one killer application for Ruby. This is a reason for you, if you're building something new, to pick Ruby as the thing that you're building it. But the important thing is that
[0:07:00] As you scale, no matter what you're doing, you're going to end up with a lot of components that aren't web components and that you're going to run across a lot of places where you don't want to do things in the Rails way because you have some need that is specific to whatever you're doing. And in that case, I think it's really important that there is a very good set of conventions and styles that will work in those cases and that I think that's something that's currently lacking and something that people kind of focus on. There's kind of this Rails ecosystem and a lot of people sort of
[0:07:29] Don't know where that ends and where Ruby begins, and as a result, that there really isn't much for them to segue into or to realize, hey, when I need to do something that looks more like general programming than pure crowd web application scaffolding and that sort of thing, what do I do? So in your talk description, you talk a little bit about tools and then static analysis, and that seems to be a conversation which is starting to happen a little bit more with Ruby.
[0:07:57] But you seem to think it needs to happen a lot more. So I think that the space that I've seen is people saying, how can we modify Ruby to make it more easily statically analyzable? And so if you look at the existing tools out there, that a lot of them are, well, we have some specific subset of Ruby or we add some annotations on top of Ruby and then we can do all these things. But I think at the end of the day that that's not, that's just fragmenting the ecosystem at best, right? Or just kind of...
[0:08:25] Something that's just never going to take off at worst. That I think what we need is we need tooling that sort of takes into account how people are actually writing Ruby now. And that I think it's one of those things where people say, hey, like, Ruby is dynamic. You know, that the actual way that classes are created, that's turned complete. That you can't just write a static analyzer and sort of know even what the set of methods on the class are. And that's true.
[0:08:51] But that doesn't mean that in the majority of cases that you can't figure out what's going on. That again, it comes back to, it turns out that things are bad style that are hard for humans to understand are also things that are hard for machines to understand. And so you should probably be avoiding doing a bunch of dynamic cogeneration anyway. And that means that you can turn a static analyzer on a limited set of Ruby.
[0:09:12] Which turns out to be the set of Ruby that people use in practice, and then if you come across cases that you can't understand, or that your tool has trouble ingesting, that you can sort of ignore those or throw warnings or whatever you want. And so I think that the one mindset shift there is don't try to get 100%, don't try to get 100% coverage, but at the same time, also, don't require people to modify their programs. And with that, you can get 95% coverage, and that there's a lot of value out of that.
[0:09:43] What is it that you really want people to capture as they walk out of your talk? I think that there are two major things. I think number one is sort of admitting we have a problem. I think that in the current world that everyone is focused on sort of one aspect of Ruby performance, but in reality there are a bunch of problems with just the way that we're developing the community and the software that is going to cause it to, in the long run, not be.
[0:10:13] A valuable language. And then the second thing is I want to present some, at least get the conversation started on potential fixes there. And I have a set of things that I know would be helpful to Stripe and that I believe would be helpful for the ecosystem generally. And I don't claim that I have all the answers, but I think that it's important that we start thinking about it. Excellent. Well, Greg, thank you so much for your time. Look forward to seeing you down here in Sydney. And look forward to your keynote.
[0:10:43] Well, thank you for having me.