 Hello! Good morning everyone! We're all excited for the weekend. It's gonna be an excellent set of talks. I looked at the list again this morning to see the final list here and I'm excited to be here. I'm excited to be here in India. I'm excited to be giving your opening keynote today. My name is Charles Nutter. You can call me Charlie. I am one of the JRuby guys, the core JRuby folks, have been working on JRuby now for almost six years, full-time, first at Sun Microsystems, may they rest in peace, and then now at Engine Yard for the past several years and we're very thankful that Engine Yard supported us. I just want to tell you all I'm really excited to meet each and every one of you, so don't be afraid. Come up and talk to me. I want to know what you're doing with Ruby and I want to know how folks like me on the JRuby team, other implementers, other people involved in Ruby can help make your Ruby experience better. So let's let's get into this now. So we're all here because of Ruby, obviously. How many of you are paid to do Ruby right now? Almost the whole room. There are a few folks who are still working on it but that's excellent. At Ruby conferences when I first started going in 2004-2005 there were one or two hands that would go up, maybe one or two hands for people that were paid to work on Ruby and they were usually people involved in the conference and setting it up and so they didn't really count anyway. They were the people pushing it forward. But now everybody has an opportunity to use Ruby, everybody's getting paid to use Ruby and it's changed so much and it continues to grow and what I thought I'd do for the keynote today is talk a little bit about where we stand as a community, what we're doing with Ruby right now, what the landscape of the community, who the people are that are doing Ruby, see what sort of challenges Ruby has in the future and then talk about how you are going to help us address them, how the implementations are going to help address them and make sure that everybody has something that they're going to go do to help Ruby move forward in the future. All right. So we'll talk on the grand scale here. The world of Ruby, the Ruby world right now. As it stands today there are roughly a million to two million. The conservative estimate is a million Ruby developers in the world right now. Across all countries, so many people that are doing Ruby, this is paid, paid work in Ruby. If we expand on this a little bit, Mott's claimed that at red.rubyconf in Singapore just recently, he actually threw out the two million number. So the original one million number was a Gartner estimate in 2009, 2010 or so. Now Mott's is hearing estimates getting numbers in the two million range. And then we go even further beyond that. Gartner's now estimating that there'll probably be four million developers by the year 2013. It's continuing to grow. And they go out and they interview all these companies and they find out what technologies they're using, what they're looking to put into production. And they see that Ruby continues to grow at a rate that'll bring it up to four million developers in 2013 and then continue to grow beyond that. So just those numbers already are amazing for a community, a language community like Ruby. And then because we have all of these people working on Ruby, there are dozens and dozens of conferences around the world. I think there are more conferences for Ruby than any other programming language, probably for any other single technology. In the United States, there's probably a dozen, 15, 20 different conferences in various areas that are all close to this size. Conferences on just about every continent and almost every major country. There are Ruby conferences that you can go to. It's a great opportunity to travel too. But it's amazing that there's that much support and that much interest in Ruby across the world. Let's take a look at a few of those. One that I went to recently, I went to RubyConf Uruguay last year, which was great for me because as a kid, we studied Uruguay. We studied Montevideo as our sister city, just random occurrence that it turned out I got to go there for RubyConf. So I went to Montevideo in 2010 and that year, their first year of the conference, Montevideo is a city of about one and a half million people. They managed to bring in 150 attendees. And that's 150 attendees when they had RubyConf Brazil, the big one, the week before, they had another RubyConf that was going to be the following week. And they still managed to bring in 150 folks. And even then they managed to have increased that the next year. 300 people came in in 2011. And in 2011, there were four or five Ruby conferences in South America. So even with an expansion of the conferences that were available for the Spanish and Portuguese South American Rubyists, they still doubled the number of people that they had come to the conference. That gives you an idea of how rapidly things are growing in Ruby right now. And then of course, we have India here. So we look at numbers RubyConf India 2010 had an amazing milestone of the most number, not the highest percentage, the most number of women attendees of any Ruby conference. And if you go to any of the Ruby conferences, the large ones, there's constant lament that we need more women developers, we need to bring more people in. So RubyConf in India 2010 had that really distinct really special milestone. Last year, 400 people, I at least I think it was 400 people came to Bangalore. So the IT center of India managed to bring in 400 people. And then here in Pune, which is not Bangalore, it's still got a lot of technology going on a lot of great companies. Does the number go down? No, it's 400 as you saw in AJ's opening. It's actually more. We got more than 400 people that are willing to come out to Pune from 35 cities, seven countries to be here for RubyConf India. Again, continuing to grow, continuing to draw more people in. I mentioned Brazil. Brazil is a big one is a massive developer community in Brazil. They have the largest Java user group in the world. And they're working on having probably the largest Ruby presence of any single country in the future. So RubyConf Brazil 2010, they had 700 people. That was maybe the second or third, I think, of RubyConf that they had had there. So 700 was a great number of people to bring in from all over South America. And you also have to consider that Brazil is a Portuguese speaking country. They managed to do a really solid job of doing multilingual translations, Spanish and English and Portuguese and brought in people from all over South America to be at the RubyConf. In 2011, they managed to bump it up even more. The venue was limiting as far as how many people they could fit, but they had full live streaming of the conference and 500 people that followed along with the conference the entire weekend. So 1200 people that they had in attendance in one way or another. And for a two day conference that had two or three tracks, 15 of the speakers did not live in Brazil. They came from different countries. So that's like a full day and a half or more of talks that were done by people from outside the country that came into Brazil and wanted to speak. Let's take a look at the United States. Obviously, the United States has the original Ruby conferences. So they started things going a little bit sooner. We'll talk about RubyConf. So RubyConf, as anybody who's tried to get into it knows, it sells out every year. In previous years, it's sold out in a day or two. They've had limited venue size. They've wanted to keep the conference small and intimate. And as a result, the conference sold out 300, 400, 600 people almost immediately. This most recent year, 2011, 850 people is the largest RubyConf that had ever been done in the United States. They managed to open up a large enough venue, get enough people in and had 850 for the first time. And that number is impressive for a Ruby conference. So far, that's the largest one that we've talked about RubyConf at 850 until you look at RailsConf. RailsConf this past year had 1,800 attendees. And that's for a web framework that is now four, five years old that's still drawing in two to three times as much as the next competing web framework in any other language every year, bringing in that number of people. And then finally, we'll take a look at Japan where Ruby came from, the heart of Ruby. In 2010, RubyKaigi in Japan hosted 2,000 people from all over the world. It was the largest single international Ruby conference anywhere. That was 2010. It went up again in 2011. I don't have the exact numbers, but in 2011, the conference got so large that the group of community organizers putting it together decided that it was just too big for a group of community folks to put together. And so they're splitting it up and doing multiple conferences in Japan now because there's so much interest and so many people want to come to Ruby conferences in Japan. So it's amazing. Ruby really is everywhere and there's so many people that are getting interested in it. So much growth, despite what people might say, despite what you might hear, there is a lot of interest and continuing growth in Ruby right now. Now, that doesn't mean that everything's perfect. There are certainly some challenges that we have in the Ruby world. Ruby has to grow just like any other technology does with new challenges, new applications, new technology. And we have to find a way to solve those. So I figured we need to get these out in the open. We need to talk about what the challenges are for Ruby in the future so that we all can work as a team to bring Ruby into the future and make sure we address all of these issues. So let's take a look at what we've got. Is anybody doing an application that they describe as a big data application? All right, there's a few. I've got some numbers that'll show you that in the next few years you're probably all going to be dealing with big data in some way. So let's talk about big data. What is big? There's been a lot of definitions. Some people say big data is more than I can imagine. That's a pretty good definition. It's more than I can process in a day. That's a pretty good, pretty good definition. So I went looking around to see what other metrics there were. Big data means massive capacity, massive amount of information that's being created, and the challenges of trying to process all that. This is actually a figure that has been true since the early 80s. Our capacity for data, the world storage capacity for data in all computer systems has doubled about every 40 months for the past 30 years. And you can imagine what the numbers are there. We're talking exabytes upon exabytes. Let's see how much we're actually creating. Right now, this is a number from middle of 2000, 2011. So it's even increased more. Every single day, 2.5 exabytes of data is being created in some form or another. Who knows what an exabyte is? You don't even know how much it is. That's big data. It's so big you don't even know how much, how big it is. So you have gigabyte, petabyte, or gigabyte, terabyte, petabyte, exabyte. It's quintillion bytes, 2.5 quintillion bytes every day being created right now. So now, that's impressive, right? That's a massive amount of data. Now, if we look at the future, 2013, it's estimated that the data flow on the internet will actually be in the neighborhood of 667 exabytes per annual data flow. Now, if you do the math there, that means that the amount of data that's being created and stored right now will be transmitted on the internet within the next two years. And you can imagine how much more data is actually going to be created at the same time because the networks never keep up with our demand for them. Look at some more metrics. So the Sloan Digital Sky Survey, basically trying to map out digitally the entire night sky. In its first few weeks, this was in 2000, its first few weeks, it gathered more information from the sky than had ever been gathered in the history of astronomy. And that's just the first few weeks that this was in operation. To date, it's gathered 140 terabytes. So this is one project that's generated 140 terabytes of sky information, digital sky mapping. And of course, that's a lot, but we top that again, right? In 2016, the largest an optic survey telescope goes online and will produce that much data every five days. And that much data needs to be processed and managed. That's big data. That's why we need to be looking at how we handle data more quickly, how we process information as fast as possible. And that's why Ruby has to keep up with the rest of the world and has to perform and has to be able to handle these massive data sets. All right, now if we're going to have all this data, we're going to process all of this data, we need to be able to do it across a wide range of processors. So what are the facts here on multiprocessing? Some of you have heard this. The free lunch is over. A lot of you have probably heard. So let's look back historically. 1978, Intel's best X86 processor, the 8086, could in one of the packages do a whopping 10 megahertz. I actually had a machine that was an X86. I had an old IBM XT with a 10 megabyte hard drive that I think cost like $15,000 or something like that. My dad bought that for his stuff. But I was the coolest kid on the block with that 10 megabyte hard drive. So 10 megahertz. Now if we look 14, 16 years later or so, we managed to get an order of magnitude increase on that, finally. 486 DX, which I also had a DX4, 100 megahertz. So we get an order of 10 improvement and it looked like this was going to continue forever. We go less than 14, less than 10 years later, the Pentium 3 was managing to run at 1 gigahertz. And so then obviously by now we should all be running 10 gigahertz machines, of course. And I'm sure we all have those, right? No, of course, it doesn't work that way. We hit a limit on how many transitions we could fit into a small package, how much data we could process. We hit the speed of light limit. We couldn't actually move data fast enough on the core of the processor to keep up with this growth. So things slow down. 2006, Core 2 duos, 3.3 gigahertz. So now we got five years and we're only getting about an order of three or three order magnitude there, or three multiplied for our original amount. And then again, another five years, we don't even get that again. 3.8 is the best you could get off of the standard processors this past year. And it's not going to go a whole lot above that. Maybe four, maybe in the mid fours sometime. But the limits have been reached as far as what we can do on a per core basis to process this data. We have to expand. We have to make it wider. We can't make it deeper. Another way of looking at this, and actually you can see there, this is, you notice something about this chip die? It's a bunch of repetition here. So this is an eight core chip. Each core has its own cache, its own memory cache. These cores need to be able to operate mostly independently to be able to process all that data. So now let's talk about cores. Since we can't make each core faster, we need to make more of them. So our good friend Moore's Law, which still still tends to be true. Moore's Law says that we can increase the number of transistors on a processor, double it about every 18 months or so. That's been the metric even going back before transistors were in silicon. You can actually trace this back and it is held true for 50 years. Now the problem here is that with core sizes leveling off, there's only so many transistors we can fit in each core. So what do we do? We're going to expand the number of cores. Now if we're going to still talk about doubling transistors size, if Moore's Law is still going to hold true, what does that mean for core counts on the processes we're using? Well, if we have eight cores in 2010, we'll have 32 by 2015 and we'll probably have as a common machine 128 core machines by 2018. So single threaded processing is just not going to satisfy the needs of computing in 2015 or 2018. We need to find better ways to multiprocess and to take advantage of all the silicon on the cores. Alright, now combining these two things. We have big data, we have lots of cores and we need to process it as fast as possible. Obviously the just straight line performance is going to be a very key part of this as well. So we've got these cores, they're not really getting faster at this point. We've got all this data that is growing exponentially. The more we can do to make to get more work done in less time, the more successful we're going to be. Each of those cores needs to be used to its maximum. All of the cores need to be saturated if we're going to get stuff done because we have to make this data work. There's just too much to crank through the systems, too much to process and this is one that's driven me nuts for years. People have said for years that you know it's okay if Ruby is not that fast. It doesn't really have to be that fast. Performance doesn't really matter, it's not that important. Now that can be true if you're running a one little small application, one little app, one server, maybe one or two instances. Yeah, performance doesn't matter then, but performance does start to matter when it gets to the point that you actually need things to run fast. When you need to be able to handle thousand transactions. So Ruby is not exempt from this. Just because we can call into other libraries, we can call into other systems, we can spread it out across a few processes. If each of those processes is taking ten times or a hundred times as long to process data as writing something in Java or Scala or JavaScript, guess what? People are not going to use Ruby. They're going to move on. Ruby is a beautiful and wonderful language, but it is not so beautiful that it can get out of a hundred times difference in performance or even a ten times difference in performance. And that's where we need to do more work. We need to do more work in libraries and obviously folks like me need to do more work at the VM level. Alright, and mobile is kind of the last area that I want to cover. Some of these numbers are just baffling because this is where a lot of the data is actually coming from, processed. So as of mid-2011 of all mobile subscribers, all mobile accounts in the United States, 43% of them were smartphones at that point and that's continuing to increase. And smartphone users use more and more data every year. The United States data providers have all now had to institute caps. They had unlimited data for a while but there's just too many of these phones out there, too many people on them. Now that actually adds up to a hundred million smartphone devices in just the U.S. alone. Now the numbers globally, the percentages are a little bit different, but it's still high. 30% of all mobile devices globally are also smartphones. So this is one of the biggest development opportunities, the biggest development platforms that are available. It's outstripping any other development platform that we have and we need to be able to bring Ruby to these platforms. We'll talk a little bit about how we're going to do that later. And then there's this number, 483 million smartphones shipped last year. Half a billion smartphones and that's continuing to grow every year. I mean, you know, people are obviously throwing a lot of phones out, but at some point everybody's going to have one of these devices and we need to make sure that Ruby is there. All right, so a little bit less technical, less actual technical challenges here. The world has decided that there is not going to be one programming language. Now don't listen to anybody that's saying that JavaScript is going to be the next language and everything's going to be written in JavaScript or it's going to be Scala or it's going to be something else. No, there's too much development, too much code being written for there to be one language that does everything. We use the right tools for the right job now. If you want to use Scala for something that Scala fits, use it. Use the right tool. What we need to do as Rubyists is accept that this is going to be a polyglot world. So let's take a look at some of these numbers. So GitHub, I don't know if people know this. GitHub actually became the top open source hosting site this past year. They just passed up SourceForge, which was originally the biggest. And I think this was mid-2011. They've probably gone much farther than that right now. On GitHub, the top two languages are JavaScript and Ruby. JavaScript with about 20%, Ruby with about 15%. I think this is a line of code. Lines of code count. But those two languages, which various people have said, is going to be the next language that everyone uses, still only account for about 35% of all the code that's on GitHub. And if you look at what's on GitHub, it's mostly new projects. It's projects that have come up in the last three to four years. So this is the language, these are the language that people are using to do new programming. It's not just JavaScript and it's not just Ruby. In fact, the top 10 languages being used for projects on GitHub, mostly new code, still only account for 85% of the code. This is a vast array of languages that are being used to put stuff together for new applications. Ruby is just one of them. And we want Ruby to be everywhere. We want it to fit into the world and we want as many Rubyists as we can. But we need to accept that Ruby isn't the only language. We need to know what these languages are, know their strengths and weaknesses, and make sure that Ruby can fit into their world as well. Now, this is, there's another dimension. Like I say, GitHub is mostly new code. So let's cut this a different way. Olo is another project site that tracks individual open source projects, regardless of where they're hosted. GitHub's numbers tend to get inflated by forks. If it's a project that's popular to fork, if they do a lot of encouraging people to fork, if they have a development process that they want everything to come as pull requests, it blots up numbers a little bit. But Olo just tracks the original source of the project and gets some of the similar numbers. So let's take a look at what this is. The top three languages there, we're talking, they track pretty much every open source project. So this is historical projects as well. C is still the top language as far as historical code that's out there and being used in projects. And actually C and C++, this breakdown is exactly the same for how many lines of code are still being committed to these projects. They're not all on GitHub, they're not all new flashy programs, new flashy libraries, but there's still more work being done in these three languages than almost all the other languages combined. New stuff, yes. We're using interesting fun languages like JavaScript and Ruby and Scala. But there is a lot of existing code out there that we still need to fit into. We need to work with the JavaScript of the world and the C++ of the world. The next 10 languages below that only add another 3.4 billion lines of code. So we're still talking about the vast majority of code that is out there in the world is not Ruby, it's not JavaScript, it's one of these languages. So when we look at how we do Ruby development or how we do JavaScript development or any of the new languages, we need to figure out what our story is dealing with C libraries and Java libraries and existing applications and existing platforms and servers. That's absolutely critical for Ruby to be successful. And in this list, things break down a little differently. JavaScript is not number one, JavaScript is sixth place, Ruby is in it eighth place. So we it's not, Polyglot is not just about using all the crazy new languages that come down the block. Polyglot is about accepting that there is a massive body of existing code out there that needs to fit into our world too. All right, so the last challenge area is the fashionable new technologies that seem to take the wind out of our sales sometimes. I think probably the most fashionable right now is Node.js. Anybody doing Node stuff? A couple folks. That's all the kids in the US are using Node now. It's the greatest thing. It solves all your problems. It makes concurrency just disappear because it's not concurrent. So let's look at an example of why these fashions are so wrong and a hilarious example of why you shouldn't always listen to these trends. You need to figure these things out for yourself. Try it out, play with it. So another language popularity measure, Tyobi, much maligned Tyobi, tracks language popularity over time. They have some historical graphs. Every year they name a new language of the year. Their results are based on Google search results, other search engines, job postings. They sort of aggregate all this together to figure out what the relative popularity of the language is, which seems like it's an okay metric, except that in early 2010, Tyobi declared their language of the year for 2009 was Google Go, which had just been announced three months earlier in November. I don't think you even download it at that point and use it, but there was so much web traffic about this. So many people talking about how Go is going to be the next thing, posting on forums, asking questions, blogging about it, that it bloated these results up. And so everybody all of a sudden said, oh my god, it's the language of the year. It's jumped up to 13th place out of nowhere. Three months and this language is everywhere. Well it wasn't quite what it seemed. Right now Go is not even in the top 50 languages on Tyobi. So don't always listen to the hype. Don't listen to my numbers even. You know go out and check this stuff out for yourself. Find out what technologies are available, try them out, and use them before you decide that this is going to be the next great thing. All right, so how are we going to fix some of these technical problems? So first off, pretty much everything that's doing Ruby right now is using Matz as Ruby, right? Let's get some numbers here. How many people are using Ruby 187? All right, I'm glad to see that those numbers are dropping a little bit. 186? Anybody have any apps still on 186? Oh, that's too bad. Got to move, got to... One of the stragglers. There's always a few, and it's okay, you know, especially if it's a legacy app and it still works, you know, whatever. We still have people that get mad that JRuby doesn't support Java 1.4, so I mean what can we do about that? How about 192 folks? That should be most of the folks there. And then 193? Okay, so 19 has done an incredible job of gaining market share over the past year, and as you can see, MRI still represents the vast majority of Ruby installs that are out there right now. As you saw from the hands here again, Ruby 1.9 adoption is accelerating very rapidly, so rapidly that Rails 4, the Rails core team has said is going to be, it's going to require Ruby 1.9. I don't know if that's set in stone, but it's probably not a bad time for it. Ruby 1.9.2 came out a couple years back, and it was solid. Ruby 1.9.3 cleaned up a bunch of stuff that they missed, and it's solid. Now's a good time to move to Ruby 1.9. And actually JRuby 1.7, which is going to come out at least in preview form in a couple months, will default to Ruby 1.9 mode now. And it'll be the first alternative implementation to actually release 1.9 mode by default. All right, no other implementation has shipped complete 1.9 support yet. I mentioned JRuby. So we still are largely following Ruby, chasing MRI. And even into the 2.0 cycle, JRuby, Rubinius, everyone else is still sort of keeping up with what's going to happen with MatzRuby. Things are slowing down and settling in 2.0, but we're still kind of catching up. So this is still the standard, and this is still what we follow. And if it works for you and you don't have problems, you're not running into any of these other issues, you keep using it. But make sure that you are still supporting MRI, and you still know what the features are that are coming down the line, because everything's going this way. All right, JRuby. This is my baby. So, pretty much everybody knows that JRuby is JRuby basically brings Ruby to the JVM, or, if you look at it differently, it brings JVM to Ruby. So what is the JVM? Give us, why do we even bother with this? Well, the JVM has been designed around big data applications, massive parallel processing applications, high performance applications. It's almost silly now when people tell me that they don't think the JVM or they don't think the Java can perform. They can do a tremendously good job of performing and processing massive amounts of data. It's far easier to process it across multiple cores than in most other languages. So these are where the JVM shines, and you get this stuff out of the box with JRuby. You just get it for free. JRuby also runs on Android devices. This is the most popular smartphone platform now, and the fastest growing by far. They've come in three years from being fourth or fifth, as far as smartphones go, to being number one worldwide. Forty-three percent of smartphone devices worldwide are now Android devices, and that's the largest percentage. All right, and JRuby uses, of course, can use anything that Java servers have available. So again, the polyglot aspect. You can use the existing libraries pretty much seamlessly. You can deploy on the existing servers. You can fit into existing organization. So JRuby's got a lot of different angles where we're helping tackle these issues. If you haven't tried JRuby, you really should give it a shot. All right, Rubinius. So one of the problems that JRuby has is that since we are on the JVM, and the JVM is very, very much abstracted across platforms, lower-level things sometimes are tricky. POSIX libraries, C extensions. Rubinius is basically a complete rewrite, complete re-implementation of a native C-level Ruby VM. It's written as C++ VM, and then the core classes are largely implemented in Ruby. That's one of the design goals. Makes it easier to maintain, easier to improve it over time. And it is the only VM that is implemented specifically for Ruby, other than Matz's Ruby, of course. There are other VMs that are built on top of the JVM, built on top of the Ejective C runtime. Rubinius is the only one that's been designed purposefully to run Ruby code, and that's going to help them in the future. At some point, they probably will be able to do optimizations that will be difficult or impossible for us to do on the JVM, because the JVM is a general platform, a general language runtime. Someday, it'll be good to get to that point. So Rubinius offers a lot of similar features, not on the same scope or scale, that the JVM does, but they offer much better garbage collector than the standard Ruby implementation. They have parallel threads now on master. It's not released yet, but it's pretty solid. There are a few folks that are running with real, real parallel threads in standard Ruby applications and still using native extensions. They've done a very good job of making C extensions work properly in Rubinius. We've got partial support in JVM, but it's a really hard problem, so I respect them for trying to tackle that one. And Rubinius 2.0, which is supposed to come out sometime soon, is also going to have 1.9 support. So again, everything is moving to 1.9. If you haven't moved to 1.9, your next project should be there. All right. Now another approach of the big data, who's heard of Maglev, you folks. Maglev is basically, it's a Ruby implementation atop the Gemstone Smalltalk VM. Now the big sell for the Gemstone products is that they have a distributed data cache across all of these instances, pretty much transparent, transactional, full-acid compliant. So when you talk about having big data and being able to process it across multiple instances, that's just built in. I mean, these products have been made for big data from the beginning. In fact, it's almost to their fault. People think, oh, I can only use this if I'm a shipping container company across 40 countries. Well, no, you can do pretty much any big data stuff with this and have the benefit of visibility of that data across all of these different instances across machines even. So what Maglev brings to Ruby is this enterprise-class object-oriented database stuff. A native JIT is based on the Smalltalk JIT for their Gemstone Smalltalk product, which also helps Ruby performance improve quite a bit. I think they, a couple years back, they were boasting that they could run the pure Ruby MySQL driver as fast as the C1 that was wrapped for MRI. That gives you an idea of how the performance goes on Maglev. And then this whole distributed shared memory cache is the big sell. If that's something that you're looking for, doing a large dataset with multiple instances working against it, Maglev might be something to look at. And then coming back full circle to simple desktops and mobile devices again, Mac Ruby is an implementation of Ruby that basically just runs atop all of Mac OS' core technologies. Cocoa and the Objective-C runtime and the Objective-C garbage collector. So it's, I kind of, I call it Objective-Ruby because that's kind of what it is. It basically allows you to use Ruby to write anything, any programs that you would use Objective-C for. Is anybody doing iOS development? Okay, there's a few folks. So right now, you can use Mac Ruby to build applications for the Mac App Store. And there's actually two or three apps that have been published to the App Store right now. And I don't know the progress of this. I don't know if it's secret, but is supposed to be possible soon to even write iOS developments entirely in Ruby with full access to all the same APIs you use from Objective-C. So that, that sounds great. I mean, if I was going to write an iOS application, I certainly would prefer using Ruby over Objective-C. Okay, so that's the VMs. That's what we're doing as implementers to try and help Ruby make it into the future and survive. Now, we need to know what you're going to do. We're meeting you halfway and we'll help make sure your stuff runs as well as possible. But what are you going to do? Well, we look at this. The Ruby community continues to grow. You've seen the numbers. You've seen all the folks here. There's more and more Rubyists out there. And even with these growth numbers, there are still way more jobs, a lot more work to be done than the available Rubyists can do. So we need to draw more people in. We need to find additional folks to work on Ruby stuff, talk to our friends, go to other events, and show them what's going on with Ruby. The work is continuing to increase all the time. Despite what people say, Rails still is the easiest way to get a web application up and going. I mean, there's... Every framework has its warps. Every framework has its growing pains. But if you want to put something up fast that has a full stack behind it, nothing is as fast as Rails yet. It's true. So we need you. We need your friends. We need your friends' friends. We need their cousins and their uncles. We need everybody. We need to show them how easy it is to build this stuff. Go out and teach some more folks. Get a user group going in your local community or participate in it. Bring folks in. One of the big programs that's been going on in the U.S. now is they have KidsRuby. They have a Rails bridge where they basically bring in non-programmers who've never programmed before and show them they can build web applications in a day. And they actually succeed to get applications up and going. You can do that here. You can do that anywhere. And that's how we're going to bring more people in and be able to fill the work that needs to be done and grow the community at the same time. And of course, Ruby itself is only part of the story. This is only one piece. We can make Ruby implementations fast. We can make Ruby run well. But it's your projects, your patches, your contributions to the community that make Ruby grow. You are the reason why conferences year on year continue to get larger, why there's more Ruby work, why the number of Ruby is worldwide is continuing to grow. So if you don't get anything else out of this conference, at least try one of the other implementations. There's five or six JRuby talks here. At least one of them has to be some domain that you're interested in. So try out a different implementation. I don't even care if it's JRuby. Try Rubinius or Maglev or whatever. If you want to get involved in projects, I strongly encourage helping out. Every single open source project out there has a stack of bugs. Rails, JRuby, Rubinius, everybody has issues that they need fixed. And we need folks like you that can come in and help. Sometimes it's just going over the bugs and confirming they're still broken. JRuby has 750 open issues, going back six, seven years. They're not all valid. But who wants to sit there and review 750 issues every six months? That's the sort of thing that somebody can come in, get a feel for where the project is at, what past problems were, and maybe find stuff that's fixed and help us just get things under control. Or start a project of your own. It's easy. If there's some library that you don't like, some library that's not being maintained, you can take it over. If there's some API that's missing, some utility that you've been using in your own projects, just spin it off. Find a way to get it out there so people can help out with your project and your project can help out people. All right. So finally, the last thing that I want to recommend here for everybody is to just stand out. Be different. That's what's made Ruby great is that we've cut against the grain. We've fought against what people have told us. Ruby is supposed to be dead five years ago. Rails was a flash in the pan. And now it's all bigger than ever. So stand out in the crowd. Don't let everybody just bully you into going one way or another. Try out other frameworks. There's a new Ruby web framework every couple of weeks. Some of the ideas get folded back into Rails. Some of them don't. Try something new. Do a project that's based entirely on Sinatra or one of the other little frameworks. Go to other conferences and user groups. Go right into the belly of the beast. Submit when there's Java conferences. Submit talks on Ruby. You can say it's J Ruby. You know? It's a total scam, but it totally works. You know, say, you know, make up some marketing title like scaling the enterprise web application with Ruby. That works. That actually works. It's sad, but... So go to these conferences. Go to these other user groups. Learn from them. I mean, the Java guys are not all dumb. They've got some great stuff. Obviously Java's not dying off. It's been growing bigger and faster than ever. There's something going on there. Learn what it is. Learn what's cool about Scala and Clojure. Learn Haskell and then put it away. But go there and try these things out. Learn from them and teach them. Show them why you love Ruby. Show them what it is that Ruby means to you and why you stay in this community and why you keep building applications year after year in Ruby. And, you know, above all, show them that you're proud to be a Rubyist. That you're proud of what you're doing. You're proud of the community that we have here. And they'll want to join you. They'll come along with us. All right. That's it. Thank you. Now, it's 45 minutes. We have time for a few questions if anybody has any thoughts. Yeah. You grab the microphone. Yeah. So Ian Ruby is still kind of a sad story. I was really excited for Ian Ruby because it is like JRuby's little brother. Just like the CLR. It's kind of the JVM's little brother or, you know, big brother, depending on which side you're on. But they were doing a great job on it. It is still out there. They spun it off completely as normal open. So I think it's actually Apache 2 license now. But I think at some point they decided that either they didn't want to continue to fund Ruby development or development on Ian Ruby or they just wanted to push those resources elsewhere. I mean, they were smart guys, great guys that were working on this stuff. And I can understand why they want to move them off to other projects and have them do other amazing things within Microsoft. But as it stands right now, I don't think anybody works full-time on Ian Ruby. It's moving very slowly. I looked at the mailing list recently in the most 10 recent emails were spam. Kind of gives you an idea of how it's going. I did email Thomas or Kamas from Microsoft to get some facts and figures on Ian Ruby. I guess he's too busy or not working on it right now. So it's sad. I really wish that Ian Ruby would continue. It's something where, you know, if you feel like you can pick up a CLR-based project, C-Sharp-based project, it's not a bad code base. If there's enough interest, that's what they expect. That's what they hope, is that they release this out in open source. They don't have the funds or the wherewithal to continue funding it. But maybe someone like you can help pick it up and keep it going. Just dive in, fork it on GitHub, and start making changes, updating stuff. That's how I got into JRuby. Other questions? Hmm? Mira? Oh, so yeah, my other language, Mira. Maybe I should do a lightning talk on that. So Mira is basically my attempt to make a Ruby syntax for writing Java. It's not Ruby, but I use a lot of the things I like about Ruby to generate Java code, essentially. That's another way that I'm trying to approach the problem of having the feel of Ruby and the parts I love, but still fitting into a Java world, as if a normal JVM sort of language. As far as where it's going and stat-wise, it's still kind of experimental, still working on it. There are people with small production apps, especially small, like mobile applications. You can write an Android app and about 10K lines of code, or not even 10K lines of code. The actual distributable is only about 10K of binary. But one thing we do have coming up is in April, we're doing a hack fest with some of the Google folks. Mid-April, probably a full week that various people will be on IRC, just trying to get it up to date and bring it to a 1.0. And I'll try and do a lightning talk about it later. Anything else? Yeah, hi Charles, great talk. Thank you so much. You mentioned about Android development with JRuby. Do you mean Rubuto, or do you mean just writing code in JRuby and deploying it? Well, so, all right, so Android development with JRuby. There I think there is a talk that's going to be about mobile development. It may talk, may touch on JRuby, I'm not sure. Rubuto is basically just a set of APIs and an application generator for making it a little bit more Ruby-like. So you have a rake task to build your app and so on. There's no reason that you couldn't just do a standard Android application. Throw JRuby in it as a jar and start tossing Ruby code over to it. Rubuto doesn't do anything special. JRuby as a jar file works without any modification on Android. So it can just be used as a Java library too. Yeah. When we talk about performance issues with Ruby, it's a problem with most of the newer languages. That's why Facebook came up with HipHop. So do we have some projects going in similar directions for Ruby? I'm not familiar with HipHop that much. I can tell you what's going on as far as performance in Ruby. On the JBM side, we in JRuby 1.7 have been working on taking advantage of invokeDynamic. And invokeDynamic is basically a new operation, a new bytecode added to the JBM exclusively for non-Java languages to use, like JRuby. We work with the JBM guys early on to make sure it performs well, make sure it did what we needed. And the performance of, for example, numerical algorithms running in JRuby on invokeDynamic versus JRuby on previous versions of the JBM can be as much as 3, 5, 10 times as fast now. So we're trying to find better ways to leverage the JBM. The Rubinius guys have their own JIT work that they're doing. They're going to be doing more type analysis over time, more profiling at runtime, similar techniques to what the JBM does, but focused on Ruby. And then even in the MRI world, there are research projects to do full system analysis while an application runs, generate C code that represents that exact application profile and then compile that down to optimize code rather than running the Ruby. And that's actually the first thing that's been able to beat JRuby's numeric benchmark numbers is that new work on Ruby 1.9, which I don't know if it's going to go live, it's a student research project, but there is a lot of work going on across the implementations to try and get Ruby to run as fast as possible. There are cases now with invokeDynamic where JRuby can do things as fast as Java, like walking data structures, essentially the same performance as you get when you do it in Java. Numbers are harder, but we're getting there. All right, right behind you. I enjoyed the statistics you shared about big data and the multi-processing bit. With Ruby, parallelism and concurrency are not first class concepts, where there are some other languages which do treat this and that portion of the process. Do you think Ruby will have to adapt as a language to support these concepts, or is that where Polyglot will kick in and our concurrency stuff will have to deal with it? Well, as far as actually adding concurrency at a language level, I'm still kind of dubious. There are languages that do that and they force you to do everything the right way as far as concurrency goes, but then you get simple cases where you're trying to do straight-line performance that isn't concurrent and you're suffering all the same overhead as you would for a concurrent case. Clojure's a good example of this. Early on, there was no way to actually mutate data structures in place. So even if you were just doing a straight-line algorithm, you paid the cost to turn through data structure, nuggets, and nodes every single time. Later on, they added a way that within a local scope, within a lexical context, you could do mutation in place because they recognized that you'd need to be able to do that. So mixed immutable, mutable environments, mixed concurrent and single-thread environments are the way things are. What I think we need in Ruby is more attention to building libraries in ways that are thread-safe, rather than using a lot of shared objects in shared state and constants and globals, making sure that you create an instance of that library and that's your instance for the threat and then that's thread-safe. This is like Charlie's four rules of concurrency that I tell people about all the time. Number one, don't do it if you're going to avoid it. That's the simplest way. Number two, if you have to do concurrency, just don't share data and that's easy. You pass around data that no one is else is using. Each thread has its own view of the world and you just work that way. Three, if you do have to pass around data, at least don't let it be mutable data. Pass around immutable copies, clone objects, clone arrays and things when you pass them to other threads, or put only frozen immutable versions of arrays and ashes in public domain, in global space. And then the nuclear option, if you do have to go to the point where you're passing mutable data around, then you do need to do the mutexing. But you should try all these other things before you even get to that point. And that's all API level. There's nothing in the language that prevents you from being a good threading programmer. These are things that you just need to learn how to do, follow the standard way. That's the biggest problem in Ruby right now is that people haven't written concurrent programs. So they're not used to doing. And it's just a matter of education. Last question. Hi Charles, welcome to India. And thanks for the great statistics. Actually, it helped a lot. My question is, what do you think are the still issues that we have with Ruby for adapting into an enterprise application? Going back to the bad press that we had for Ruby, like memory leaks and, okay, things were coming back like we had GL, we had green fibers, green threads and all that. But we still had a great, a lot of bad press about Ruby that it cannot scale. A lot of people wrote about that. So now with 1.9.3p, 125 release, are we out of that mountain? Have we crossed that mountain? Or are we still having some issues with Ruby for which to be adapted into the enterprise applications? And we are, again, having so many implementations. There is JRuby, there are so many different kind of Ruby's available. We had Rails, we had Moab, both merged. Can we merge the best of the two Ruby's and bring one Ruby and everybody is not confused about using thousands of Ruby's for various, various projects and have one and simplify the life? Well, so, okay, so there's a few things here. I'll try and go through these quick. So first of all, it's still kind of an open question whether the Merb and Rails merge was actually the greatest idea. So I won't touch on that too much. As far as getting Ruby into the enterprise, I think the biggest problem with getting Ruby into the enterprise in the past is that it was, it's still its own little world, its own new domain. Enterprises that aren't running a technology won't run a technology. And it takes a decade or more to convince them to do that. That's why I spent so much time on JRuby. I felt like JRuby, and then again, it's one of the reasons I'm sad about Iron Ruby, I thought these were the most likely ways we were gonna get into these large organizations because JRuby can just be another Java library and just run on regular Java servers. At the same time in JRuby we had concurrency, we had real parallel threads, and we had to drag people kicking and screaming into the concurrent parallel processing world. We worked with the Rails guys to make sure that was thread safe. There's not a week that goes by that I don't find a library that needs work and I sit down and I tell them why and I slam their head into the code and say you cannot do this, this is not safe. It's just a constant education process to get them to that point, but we are getting there. I don't want you to think that I don't like MRI either. Ruby 192 and 193 are massive improvements over Ruby 1.8. So much so that the Fusion guys are not even going to try and carry Ruby Enterprise Edition forward to 192 and 193. They don't need to. It solved a lot of the GC problems. Ruby 2.0 is supposed to even have copy on write logic built into it. So all of the features, the Ruby core team is learning from what JRuby and Rubinius and everyone else does. At this point technically I don't think there are really a lot of limitations as far as getting Ruby into Enterprise. I think the problem is that they're now looking at, oh, how can we get node into the Enterprise and how can we look at doing more closure or more Scala. So the hype train that we had a few years ago has kind of passed. That's why now we need to go out and do the work and show enterprises that they can build large apps, they can make them scale, especially if they're running with something like JRuby and running in thread safe mode, get out there and actually put it in their face how much they could save man hours, CPU hours by putting this stuff out there and technically we can do it. We can make those apps work now. And that's all the time I have. So have fun, I'll see you the rest of the weekend.