Five.new

Koichi Sasada recently presented a brand new talk at RubyConf a few more details about Guilds, his proposal for concurrent AND parallel programming in Ruby 3. He repeated the motivations behind Guilds, which are that Threaded programming is very difficult in Ruby, that there should be an easier way to make correct concurrent programs, and even more interestingly that it should possible to run these concurrent programs in parallel which is currently impossible with Ruby Threads, leaving multiple CPU cores on server underused.

It's somewhat revealing that Koichi walked on stage with a black t-shirt adorned with "Kill Threads!" written on it. While that glimpses at his feelings on the matter, he did reiterate that Guilds is still simply a proposal for Ruby 3 whose name could change. So nothing is written in stone, and he's encouraging discussion on the topic.

Koichi expanded a bit on the struggles that Guilds will face in order to be implemented: like Ruby global data, object invalidation when they're moved between Guilds. He also talked a bit more about the plans for its implementation. While he wants to start working on Guilds in 2017, there are yet no clear plans about whether Guilds will be introduced in minor Ruby versions like 2.6 or 2.7 or if it will have to wait for Ruby 3. Finally he also explained that not all existing Thread code will be able replaceable with Guilds but he expects most of it to be.

The bottom line appears to be that if Guilds is indeed the future of concurrent and parallel programming Ruby, there's still a lot to be discussed since it will inevitably impact a lot of things in Ruby itself.

If you've listened to the first episode of Ruby Facets, you may know how much I love Avdi Grimm's excellent short-form Ruby Tapas screencast series.

This week — and this our first official scoop — there's something new at Ruby Tapas. Remember how a minute ago I just talked about Guilds and Threads? As it happens, Avdi once published a great episode of Ruby Tapas in which he talks about the very pitfalls that Guilds will hopefully soon address.

This screencast — titled "Understanding Ruby Thread-Local Variables" — is now free for anyone to watch. Yes, that includes you. So you can cram on good threadsafe code practice before Ruby finally makes it much less of a headache to deal with.

But instead of just flipping the switching from paid to free, Avdi turned this episode into a blog post which will help you understand what Threads are about and why they're so damned tricky to deal with.

If that wasn't enough, he also extended a kind offer to Ruby Facets listeners. You can receive 10% off of any Ruby Tapas subscription by using the coupon code "rubyfacets".

Not only is this good for your brain and wallet, but by supporting Avdi's great work you'll also be helping fund the production of Ruby Facets since we'll receive a small percentage of your first month's bill at Ruby Tapas. So thank you in advance.

These past few weeks have been filled with a ton of new Ruby versions.

There was 2.2.6 and 2.3.2 which were simple bugfix releases that included new SSL certificates for RubyGems. Closely followed by 2.3.3 which fixed a regression with module Prepend. I'm still not quite satisfied with the [ChangeLog][2-3-3-changelog] provided with these releases but I'm working on a tool to group changelog items by Ruby Core APIs in order to make some sense of them, sort of like Rails changelogs.

But that's not all, Ruby 2.4.0-preview3 was also released. And it looks like this upcoming Christmas gift will bring some nice performance boosts.

For example, the new Regexp#match? method is about three times faster than any of the existing match methods previously available. The Array class now defines its own #min and #max methods that are almost twice as fast as the Enumerable equivalents.

Beyond performance improvements, there are a slew of interesting changes covered in a very thorough blog post published last summer on the Blockscore blog and titled New Features in Ruby 2.4.

Ok, one more Ruby 2.4 item not covered in that blog post I just mentioned, and instead spotted by the good people at bigbinary.com.

2.4 will also bring most delicious Hash#compact and Hash#compact! methods. Why would you want to compact hashes, I sincerely imagine you asking? Well, let's say you have a properly parsed JSON response in which several keys have nil values.

Poof!

A quick call to compact!, and gone are the keys for the nils.

In my 7 years writting Ruby applications, I think I've had the urge to add or change something in Rails about 100,000 times. Of these urges, only a handful of tiny, and barely significant ones turned into actual contributions.

It's very easy to be discouraged by lack of knowledge, time, or motivation. But then you come across a blog like Writing a Rails Feature - Blow by Blow. This post is a detailed diary of the inception, conception, eventual implementation, and release of a Rails feature by Richard Schneeman.

While the eventual feature itself is obviously useful, what's really compelling about this post is that documents something you see far too rarely: the thought process behind an open source contribution. It doesn't always make sense for that thought process to happen in public of course, since it often involves arcane knowledge of a very particular set of problems. What's heartening however, is to witness that the work doesn't magically happen or get willed into existence by wizards and witches.

It's sometimes slow, or is forgotten for a while, or it can even stop abruptly when reality kicks in and builds start to break. The blost post is definitely not short, but if you've ever considered pitching in, you owe it to yourself to read it.

If you've ever raged at indefinite spinners suddenly cropping up on websites that used to fully render in less than a second, then it's possible than you too have had some doubts about the looming hegemony of front-end frameworks.

It's sort of easy to cast these doubts as cranky Ruby developer complaints until you read something like Jerod Santo's Why We Chose Turbolinks.

While the back-end of the site is actually built using Phoenix and Elixir, the front-end is powered by Turbolinks. Yes, the turbolinks that everybody else seems to be disabling in Rails instead of giving it fair chance.

Jerod encourages developers to increase the burden of proof for the necessity of front-end frameworks. Since there was only one interface element in changelog.com that needed to persist across pages on their site, the team decided that it made more sense to avoid bifurcating the codebase, increasing the JavaScript payload, and choosing a framework. Surprisingly, the rewritten Turbolinks 5 was basically a drop-in solution, with a few documented gotchas. So it might be time to give Turbolinks another look.