As some questions have been raised about how the Rails project’s governance functions, we’d like to clarify how the team is structured and how we operate:
Ruby on Rails is an Open Source project run by the Rails Core team. In addition to the Core team we have two additional teams - the Committer team who can merge code changes, as well as the Issues team who can triage issues and merge documentation changes.
There are 11 members on the Core team who work for various employers or are independent consultants. We make decisions and work towards consensus as a team when needed. We each strive to make decisions that are best for the Rails framework and community. The members of the Core team are:
Xavier, Independent Consultant
Guillermo, Treasure Data
Kasper, Independent Consultant
Through that consensus process, no one on the Core team, or their employers, have sole control over the framework or community. There is no individual or subset of individuals who have power to enact policies unilaterally in the Rails community spaces that we operate (for example on issues, pull requests, or the forum).
We encourage contributions from everyone and will work to make your experience as welcoming as possible.
We care deeply about the Rails community. The work we do on the framework is for you. We will continue to work at making Rails a great framework as well as a vibrant, diverse community of users and contributors.
In the first post in the Ruby Garbage Collection Deep Dive series, we went through a few definitions to give us a picture of how Ruby stores values in memory. If you haven’t read it yet, read it first! We’ll build on those definitions in this post. Particularly, we’ll talk more about the Ruby Heap, Pages, Slots and RVALUES.
Okay, now that we have those baseline definitions out of the way, this post is going to explain the algorithm Ruby’s garbage collector uses to determine which objects it can collect: the Tri-Color Mark and Sweep algorithm. There are two phases to this algorithm. You guessed it: marking and sweeping. In the marking phase, the garbage collector marks all slots which contain accessible RVALUES. In the sweeping phase, the garbage collector clears the RVALUES out of all slots which are not marked. Let’s dig in!
With the Ruby 3.0 release, there’s been a lot of chatter about concurrency, parallelism, and async IO.
For my own reflection, I wanted to write down what that means for performance and capacity/costs of apps, and what would be the impact on the Ruby ecosystem.
I will assume that the audience already knows the difference between threads vs processes model in UNIX and the Little’s law.
Following up on my last blog post, I am going to look at how Ruby is used to get a bit of an impression of whether there are major differences between Ruby and Smalltalk in their usage.
Again, I am going to look into the structural aspects of code bases. This means, looking at classes, methods, modules, and files.
When Basecamp launched in February of 2004, we ran on a single shared Linux server at Tilted. I don’t fully remember the CPU spec, but I do remember that we had the same 256MB of RAM available. And I believe the monthly cost for this princely server was around $349. It was not only fast enough to run Rails and Basecamp, but good enough to do so on its own for more than a year while we built a business that could pay the salaries of four.
So forgive me if the zombie theme of “Ruby is so damn slow” isn’t striking a recognizable tune with me. Now, I don’t for a minute doubt that Ruby may well be too slow for some people doing some things. But given the fact that Ruby was plenty fast for me in 2003 on a bootstrapped budget with the performance of the day, I think perhaps that tune is out of key for many others too.
We built an application used by millions of people that has made tens of millions of dollars in real money and continues to grow and prosper. No, it’s certainly not Internet Scale™. And it certainly doesn’t prove that Ruby is fast enough to be economical when you get there, but it does lodge an anecdote that it’s probably more than fast enough for most people doing most things.
With Ruby 3.0 just around the corner, let’s take a look at one of the highlights of the upcoming release: Ruby Type Signatures. Yes, types are coming to our favorite dynamic language! Let’s see how to take advantage of them by adding types to a real-world open source project and looking at the finer points of the process.
We are pleased to announce the release of Ruby . From 2015 we developed hard toward Ruby 3, whose goal is performance, concurrency, and Typing. Especially about performance, Matz stated “Ruby3 will be 3 times faster than Ruby2” a.k.a. Ruby 3x3.
Ruby 3x3 announced that Ruby 3.0 would be three times as fast as Ruby 2.0. It was an audacious goal, especially for a language released in 1995.
Ruby 3 is due to be released in less than a month. They’re hard at work on some of the features, but non-JIT performance is pretty close to release speed. If they pull another 5%-10% speed increase at the last minute (which happened for Ruby 2.5!) it’ll be surprising. The current performance is basically the “real” Ruby 3 performance.
So… Did it happen? Is Ruby 3 really three times the speed?