Time to read: 6 min read
This year we had the chance of getting some tickets and making it to the RubyConf directly from Uruguay (9,735.75 km / 6,049.51 mi - in a straight line -) with our team. A truly enriching experience with a great mission, making our team better. We know that the only way of becoming our better version is by living and sharing new experiences with others, so that's what we do.
The whole trip started in Dallas, Tx, where one of our clients is established. We spent the whole first-week working shoulder to shoulder with the team. We walked around the city, visited iconic buildings, tasted typical chili dishes, and overall had a great time altogether in a new town.
Then it was time to leave the lovely city of Dallas to head to Denver, where RubyConf was waiting for us. On Sunday morning, we decided to prepare our minds for the Conf, so we rented a car and went trekking on the Rocky Mountains. (A whole unimaginable day in the mountains).
Ok, enough introduction for now. It's time to dive into the main topic. What we learned from the conference and where Ruby is heading.
This year was our first time at RubyConf, but it was not a regular conf for us; we also had the pleasure of sponsoring it. Ruby has been with us since our very beginning. Supporting our working ecosystem has always been around, and we could finally make it. 🎉
Today, we are exactly one month away from having a new minor release at Ruby. As usual now, each December 25th, a new Ruby version is released; this year is not the exception!
As in each conference, this year's keynote was kicked off by Matz. It started with a summary of the current state of the art and the new challenges.
As you already know, Ruby 3.0 introduced changes to 3 significant areas:
For more details on what Ruby 3.0 brought, I recommend checking the official Ruby 3.0 release notes
We are exactly one month away from the next big Ruby release, so what will it bring?
Performance, tools, performance, tools, and performance.
Does this mean Ruby will stop releasing new features for some time?
That seems to be the approach. With the release of Ruby 3.0, new features and enhancements appeared, and now it's time for the core team to make a pause features-wise and focus on improving those existing implementations and benchmarks.
Since the very beginning, Ruby has targeted towards providing an outstanding development experience to increase developers' happiness and productivity, all from the language itself.
Now the focus is slightly different. On top of the already great language we have, User (Dev) experience will be from tools.
"We need smarter tools", "Tools are more important today" that's the premise behind the motivation of Ruby 3.1 changes to be released next Christmas.
Some of the tools the Ruby ecosystem has plenty of space to improve are better:
It's not only the matter of having more and more, but better.
As we all know, Ruby has been a Human Oriented language since the beginning. Due to that, its performance hasn't been the core focus behind the design. However, the language still needs to be performant to keep allowing us to build great production-ready applications. Ruby is heading to be a faster language.
To understand how the language performs, it's essential to have nice benchmarking tools, and that means also improving them.
The commitment for Ruby 3.1 is to keep improving the overall performance of the language but also improve micro-benchmarks. They are a critical part of the process not only because people trust them but also because they are the way to measure progress.
Matz has officially announced at the conference that Ruby3.x will be 3 times faster than Ruby 3.0 (in some benchmarks).
This incredible effort comes with a better JIT compiler; probably, a lightweight JIT will be added. There has been a considerable effort to integrate the YJIT compiler Shopify created into Ruby 3.1. Still, the reality is that we are exactly one month away from the Ruby 3.1 release. That seems to be a pressing issue that might eventually delay the end of the integration into a future release (Ruby 3.2 probably).
There is more news on top of the YJIT integration. The goal is to have a multi-layer JIT where most of the code runs in the VM initially, and then some hotspots will be compiled by the lightweight JIT, like YJIT. At the same time, the heavily optimized MJIT will compile heavyweight hotspots. This is not yet confirmed, but the idea is around having multiple layers where each one is better at some kind of compilation.
YJIT improves the performance of regular applications by 10-15%, which is already a considerable enhancement, yet there is hope Ractors will evolve and get faster by refactoring the current solution. This will also be followed by the N:M Ractor implementation, which translates as N x Ractors on M x Native Threads.
Currently (in 3.0), the relation is 1:1 - that means N Ractors running on N Native Thread)
I took away from the conference that Ruby will not have many language enhancements soon. Does that mean there will be no more features until Ruby 4.0? We don't know, but it might be the case. The focus is on improving current implementations.
If you want to be part of the improvements for Ruby 3.1 and beyond, there will be an excellent opportunity for you. Matz announced the Shootout Improvement Challenge.
It consists of the following:
It's worth mentioning that the Ruby associations are still evaluating the details for implementing this plan so that detailed regulations will be announced shortly.Follow us :: Follow me
We can help your business ideas thrive, shoot us an email!