Bio Dr Nic works at Engine Yard as VP Technology, responsible for Engine Yard’s Software Distribution and Database teams and its Open Source program. He is excited about the technologies and processes for making Rails application hum in production, for the automation and simplification of development, continuous integration, deployment and the ongoing parenting of a production web application.
RailsConf, co-produced by Ruby Central, Inc. and O'Reilly Media, Inc., is the largest official conference dedicated to everything Ruby on Rails. Ruby on Rails is an open-source web framework that's optimized for programmer happiness and sustainable productivity. It lets you write beautiful code by favoring convention over configuration. Learn more about Rails on rubyonrails.org
1. My name is Obie Fernandez and I’m at RailsConf with Dr. Nic, Vice President of Technology at Engine Yard. I’d like to ask you about some of the topics that you broached in your keynote speech today.
The premise is that I want Ruby to be the language I get to use forever. It’s very personal, it’s just about me and my gut feeling, and I’m not alone, obviously, is that MRI just technically can’t be that language. No one is going to invest the time to make it multithreaded and they have rules around what can be added into MRI, like you can’t make it slower. It's very hard to add major features and there are some constraints around not wanting to break the C extensions when they do 1.9 which meant that they couldn’t really replace the garbage collector so we have an old garbage collector, we have an 18 year old code base. None of these things are implicitly bad or evil, it just makes it more difficult to say with a straight face that MRI is the thing that we are going to be using in 5 years time.
Yes, because he is a core committer and that’s a good joke.
MRI 1.9.2 is still faster than Rubinius and I think it’s on par with JRuby at the moment and it has a faster boot time, so it makes it good for scripting and Ruby was built to be a scripting language 18 years ago. He wanted a better scripting language. It wasn’t built to do all the things we do with it. It’s like Node wasn’t built to do the things that people want to do with it now, but they’ve liberated it and they want to do stuff with it. We want to take the gift we’ve been given, which is the language and all the stuff that comes above Ruby and all the different implementations and I talked about Rubinius, JRuby and I mentioned MacRuby to show that there are different reasons for these things to exist. Rubinius itself is built really to be the successor to MRI.
I say that because that’s the shortest possible answer. A lot of us have been around when Evan Phoenix and the other Rubinius core developers [introduced] the open commit policy, there are 279 core contributors that have core commit rights.
6. To Rubinius.
Theoretically. That’s many different people, if you do the summary, but I would say there are a few that commit regularly, but he’s been talking about this for 4 and a half years for now. So a lot of us have heard different reasons of why Rubinius existed. It existed because of the challenges dealing with the governance model around MRI: the fact that it’s Japanese orientated, it's a status symbol - Matz is a national treasure, and just the Japanese dev mailing versus the English Ruby-talk list. None of these things are the core reasons that this is bad, but they don’t help. Matz is now working on Rite , more so than he on MRI, for example. One of the reasons for which we wanted a Ruby that represented who we were is we wanted a Ruby that was built in Ruby which sounds inherently slow because we already weren’t that impressed with the performance of Ruby. Why would you build on top of that?
It sounds like it’s a world of pain and a yak shaving exercise but what happens is that when obviously your code, when a whole bunch of the stack of Ruby is in Ruby and you start to optimize Ruby with a JIT, a Just In Time Compiler, it means that your Ruby actually gets faster and so it can actually be faster to have a whole portion of it in Ruby.
The Java environment for example has different JVMs that are out there HotSpot and all the different ones can have different GCs that you can pick based on the type of problems. MRI has one and it’s old and behaves in a certain way. REE, the Rails Enterprise Edition, gained huge popularity, for sometimes not necessarily good sound technical reasons, but because it allowed people to tweak the GC to optimize around what their app was. Certainly, Rails has more and more hit some of those boundaries all the time and it's causing slowdowns. Aaron talked about what he was trying to do to make it better and it’s great that he is going to spend his time focusing on making Rails especially better with memory, better with I/O, better with CPU usage.
JRuby has been rock solid for a very long time. The most recent releases, the 1.6 branch which just came out at the start of the year now has 1.9 compatibility, so you can choose whether you want to have a 1.9 parser or 1.8 parser. The most important part is that JRuby and what Rubinius will also provide is that you can have threading, you can have a proper GC without having to say "Go to an ultimate syntax". So for the MRI users, if you want a faster Ruby we have to upgrade our syntax, we have to go to 1.9, we have to do an upgrade dance or at least be aware of where we’re going. But now, what it means is that you get all this sort of stuff without having to worry about it.
Obviously, JRuby has probably been marketed and sold as a solution to people who wanted access to the Java or Java people, a bridge across into what we have. They can’t just give up their code. Big companies are building Ruby apps on top of it, Java back-ends.
Why we do that is very important, because we are still probably one of the bigger companies who take an emotional ownership of Ruby. I mean we don’t own it, there is nothing to own. We don’t own any aspect of any of the Rubies we sponsor. We spend millions of dollars and it's part of helping Ruby win because we think it’s just better for people, it’s better for developers, which means they make better products and it’s better for code bases. And it’s a better thing for cloud computing, it’s more agile, you can build apps and the time pressure on everything is coming down. People want to deploy apps faster, they want to build apps faster and I really don’t see another framework or environment that can compete with Rails in this, that scales upwards.
There might be other frameworks that can make fast apps that are small but are you going to be regretting that later on. And the Rails code base has shown time and time again that it scales, so I’m still pretty confident that the Ruby space is the space for us to be investing in.
Yes, a lot of us are getting old and have children.
There are more people coming in. Somehow you get the feeling sometimes that there is not this constant awareness that everyday new people are coming to find Rails. We did the RailsInstaller, which to me was low-hanging fruit. It was obvious that someone had to build this thing. It was hard to build because I had to find someone who wanted to solve that problem, but it was this problem that we were telling new people that...
RailsInstaller is a one-click installer for being able, on Windows currently, to get started with Rails. You install it and the command line has rails new and it just works. We install SQLite and the database and everything, we install Ruby, we install Rails, we install DevKit, which is an important part of some of the gems, we install Git.
No. People ask "Why do you use Git?" - Git isn’t important. The point of us giving you this gift pack, of this welcome kit to Rails is we want you to take the next step and become part of the community. We want you to be part of everything what we hold to be important and valuable. And you need Git to be able to use our product - not just our product, some of our competitors are bound to Git too, so we want to make it simple for people who are coming to our community. This is the technology; there are a lot of other things that the whole community could be doing to make it easy for new people. That’s what I worry about, those are some of the things I worry about.
My talk tomorrow is on Ruby clubs because I think Ruby clubs could be "Spend a little bit more time worrying about the people that I’ve never see before". Say "How are you? Hi, I’m Dr. Nic. Welcome to my club! This is my clubhouse".
I push out the community concept to the smallest possible endpoint and have a lot of clubs because ever conference is nice and regional conferences are great, but they are once a year in your region. Your club could be once a month, it could be once a quarter, it could be once a week. The talk tomorrow is about this idea of taking some of the Toastmasters ideas of how they have clubs lots of different types of clubs: morning clubs, lunch-time clubs, office clubs, university clubs. They all have a different texture to them, a different flavor. Why can’t we do that with our Ruby clubs?