Artwork

Content provided by Olivier Lacan. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Olivier Lacan or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.
Player FM - Podcast App
Go offline with the Player FM app!

Two.new

6:39
 
Share
 

Archived series ("Inactive feed" status)

When? This feed was archived on April 12, 2022 03:30 (2+ y ago). Last successful fetch was on March 12, 2021 19:08 (3+ y ago)

Why? Inactive feed status. Our servers were unable to retrieve a valid podcast feed for a sustained period.

What now? You might be able to find a more up-to-date version using the search function. This series will no longer be checked for updates. If you believe this to be in error, please check if the publisher's feed link below is valid and contact support to request the feed be restored or if you have any other concerns about this.

Manage episode 174368550 series 1401778
Content provided by Olivier Lacan. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Olivier Lacan or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.

Intro

Welcome to Ruby Facets. I'm Olivier Lacan and every week on this show I'll talk to you about a few interesting things going on in the Ruby community.

Concurrency in Ruby 3 with Guilds

Earlier this month Koichi Sasada presented his proposal for a new concurrency model in Ruby 3 called Guilds.

His goals are to retain compatibility with Ruby 2, allow for parallelism, reconsider global locks that prevent parallel execution, try to allow fast object sharing, and provide special structures to share mutable objects.

Since I spent the better part of this week trying to understand how Guilds may work in order to explain them properly, I've actually published a blog post titled Concurrency in Ruby 3 with Guilds just yesterday. I'll give you the cliffs notes and you can catch up with that post if anything sounds confusing.

There are already two ways to attempt concurrency in Ruby: Threads and Fibers. Although you create Threads yourself, their execution is scheduled by the operating system, Fibers however can be scheduled manually. Guilds are a new layer of abstraction built on top of both. Each Guild contains at least one Thread, which in turn contains at least one Fiber.

Threads from different Guilds can run in parallel while Threads in the same Guild can't. Objects from one Guild can't read or write to objects from another Guild. That is, unless you're using immutable objects.

By making the sharing of mutable objects harder, Guilds can operate concurrently without running the risk of both accessing and modifying the same objects, which would cause race conditions and bugs.

Now it gets even more interesting. Mutable objects from one guild can be copied to another guild, and even fully transferred, making them inaccessible to its original guild. An attempt read or write to them will then cause an error.

Why go through all this trouble? Well one clear reason is performance. With truly parallel execution, Ruby would able to do things it's currently unable to do, giving it powers that are currently making some people reach for other languages. My favorite part of this proposal is that it takes inspiration from other languages like Elixir, and still manages to focus on making things easy on developers. Let's hope we hear more about Guilds very soon.

The Next Ruby

Speaking of Ruby evolving, Tomasz Wegrzanowski published an interesting piece on the bits of Ruby that could be improved if we didn't care so much about backward-compatibility.

Beyond the simple desire to remove "end" statements by adopting Python-like whitespace sensitivity, Tomasz brings some very interesting remarks on the absurdities of module nesting and constant resolution, the still half-baked integration of keyword arguments into the send method, or the silliness caused by to_sym and to_s methods when it comes to dealing with hashes.

But I think some of his most interesting suggestions involve new concepts, like the idea that methods on a class could be namespaced using colon-delimited prefixes in order to make convenience methods on core classes like String and Integer more sustainable: for example with the classic Ruby idiom 2.hours + 30.minutes, which could become 2.time:hours + 2.time:minutes.

To be sure there not so great ideas in the post, but a very insightful comment by Charles Nutter (of JRuby) gives the post some much needed context. I highly recommend the read.

Ruby Tapas 2.0

Last week, Avdi Grimm published the four-hundredth-and-fourty-sixth episode of Ruby Tapas. I remember when Avdi started Ruby Tapas in September 2012 and it feels like it was yesterday. In my mind there is no better successor to Ryan Bates' amazing RailsCasts series than Avdi's short, focus, and always insightful screencasts on Ruby.

Last spring, Avdi released a brand new site for Ruby Tapas which surfaces the huge collection of Ruby topics he's managed to cover over the past four years. There's a hefty freebies section where you can get a taste for the chef's style, but if you want to get up close and personal with Ruby I'd highly recommend subscribing to access his premium episodes. It'll cost you 18 bucks a month and Avdi's not even paying me to recommend this. That's how good it is.

Programs that rewrite Ruby programs

Tom Copeland went over some of the most creative and useful ways in which some Ruby programs write other Ruby programs. Having recently upgraded a large Rails application through multiple versions I definitely support his praise of Yuji Nakayama's transpec which can rewrite RSpec 2 specs to follow RSpec 3 syntax in multiple passes.

Tom took a look at how transpec achieves this, and it's just as impressive as the end-result. transpec parses your code and converts it to AST nodes. It has classes specializing in rewriting nodes like the chunks of code using the old ShouldReceive syntax into the new expect syntax, but instead of directly replacing the old syntax with the new, transpec uses a queue which allows it to detect possible collisions between rewrites.

Tom also goes over similar gems like rails5-spec-converter, and rubocop. In times when many envy the features of more static languages, it's good to remember that some of Ruby's dynamic magic is also part of its strength as a language. I encourage you to read Tom's entire post, which you can find in the shownotes.

Keep Ruby Weird

Keep Ruby Weird is happening in Austin on October 28th this year. It's a single-day, single-track conference put on by weird but nice folks like Caleb Thompson, Britt Ballard, Terence Lee, and Richard Schneeman.

Speakers this year include the wonderful Katrina Owen, Nick Means, Kylie Stradley, Justin Searls, Craig Kerstiens, Marty Haught, and Thomas Enebo.

If you're a new or old Rubyist, there's no better place to get a jam-packed day full of fantastic talks, people, food, and conversations than this weird little corner of the Ruby. As I'm saying this, there are only 24 tickets left, so... ORDER NOW! They're 200 dollars which is considerably cheaper than huge majority of conferences.

Outro

If you'd like to support this show, please take a few itty bitty seconds to leave a review on iTunes or Google Play.

I would also deeply appreciate your donations to help me produce the show in my free time without any sponsors. You can make recurring donations on Patreon or one-time donations on rubyfacets.com

Our dreamy little music was created by bensound.com and this episode was edited by Jamison Rabbe.

Thank you for listening and I'll be back next week with more Ruby Facets.

  continue reading

8 episodes

Artwork

Two.new

Ruby Facets

51 subscribers

published

iconShare
 

Archived series ("Inactive feed" status)

When? This feed was archived on April 12, 2022 03:30 (2+ y ago). Last successful fetch was on March 12, 2021 19:08 (3+ y ago)

Why? Inactive feed status. Our servers were unable to retrieve a valid podcast feed for a sustained period.

What now? You might be able to find a more up-to-date version using the search function. This series will no longer be checked for updates. If you believe this to be in error, please check if the publisher's feed link below is valid and contact support to request the feed be restored or if you have any other concerns about this.

Manage episode 174368550 series 1401778
Content provided by Olivier Lacan. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Olivier Lacan or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://player.fm/legal.

Intro

Welcome to Ruby Facets. I'm Olivier Lacan and every week on this show I'll talk to you about a few interesting things going on in the Ruby community.

Concurrency in Ruby 3 with Guilds

Earlier this month Koichi Sasada presented his proposal for a new concurrency model in Ruby 3 called Guilds.

His goals are to retain compatibility with Ruby 2, allow for parallelism, reconsider global locks that prevent parallel execution, try to allow fast object sharing, and provide special structures to share mutable objects.

Since I spent the better part of this week trying to understand how Guilds may work in order to explain them properly, I've actually published a blog post titled Concurrency in Ruby 3 with Guilds just yesterday. I'll give you the cliffs notes and you can catch up with that post if anything sounds confusing.

There are already two ways to attempt concurrency in Ruby: Threads and Fibers. Although you create Threads yourself, their execution is scheduled by the operating system, Fibers however can be scheduled manually. Guilds are a new layer of abstraction built on top of both. Each Guild contains at least one Thread, which in turn contains at least one Fiber.

Threads from different Guilds can run in parallel while Threads in the same Guild can't. Objects from one Guild can't read or write to objects from another Guild. That is, unless you're using immutable objects.

By making the sharing of mutable objects harder, Guilds can operate concurrently without running the risk of both accessing and modifying the same objects, which would cause race conditions and bugs.

Now it gets even more interesting. Mutable objects from one guild can be copied to another guild, and even fully transferred, making them inaccessible to its original guild. An attempt read or write to them will then cause an error.

Why go through all this trouble? Well one clear reason is performance. With truly parallel execution, Ruby would able to do things it's currently unable to do, giving it powers that are currently making some people reach for other languages. My favorite part of this proposal is that it takes inspiration from other languages like Elixir, and still manages to focus on making things easy on developers. Let's hope we hear more about Guilds very soon.

The Next Ruby

Speaking of Ruby evolving, Tomasz Wegrzanowski published an interesting piece on the bits of Ruby that could be improved if we didn't care so much about backward-compatibility.

Beyond the simple desire to remove "end" statements by adopting Python-like whitespace sensitivity, Tomasz brings some very interesting remarks on the absurdities of module nesting and constant resolution, the still half-baked integration of keyword arguments into the send method, or the silliness caused by to_sym and to_s methods when it comes to dealing with hashes.

But I think some of his most interesting suggestions involve new concepts, like the idea that methods on a class could be namespaced using colon-delimited prefixes in order to make convenience methods on core classes like String and Integer more sustainable: for example with the classic Ruby idiom 2.hours + 30.minutes, which could become 2.time:hours + 2.time:minutes.

To be sure there not so great ideas in the post, but a very insightful comment by Charles Nutter (of JRuby) gives the post some much needed context. I highly recommend the read.

Ruby Tapas 2.0

Last week, Avdi Grimm published the four-hundredth-and-fourty-sixth episode of Ruby Tapas. I remember when Avdi started Ruby Tapas in September 2012 and it feels like it was yesterday. In my mind there is no better successor to Ryan Bates' amazing RailsCasts series than Avdi's short, focus, and always insightful screencasts on Ruby.

Last spring, Avdi released a brand new site for Ruby Tapas which surfaces the huge collection of Ruby topics he's managed to cover over the past four years. There's a hefty freebies section where you can get a taste for the chef's style, but if you want to get up close and personal with Ruby I'd highly recommend subscribing to access his premium episodes. It'll cost you 18 bucks a month and Avdi's not even paying me to recommend this. That's how good it is.

Programs that rewrite Ruby programs

Tom Copeland went over some of the most creative and useful ways in which some Ruby programs write other Ruby programs. Having recently upgraded a large Rails application through multiple versions I definitely support his praise of Yuji Nakayama's transpec which can rewrite RSpec 2 specs to follow RSpec 3 syntax in multiple passes.

Tom took a look at how transpec achieves this, and it's just as impressive as the end-result. transpec parses your code and converts it to AST nodes. It has classes specializing in rewriting nodes like the chunks of code using the old ShouldReceive syntax into the new expect syntax, but instead of directly replacing the old syntax with the new, transpec uses a queue which allows it to detect possible collisions between rewrites.

Tom also goes over similar gems like rails5-spec-converter, and rubocop. In times when many envy the features of more static languages, it's good to remember that some of Ruby's dynamic magic is also part of its strength as a language. I encourage you to read Tom's entire post, which you can find in the shownotes.

Keep Ruby Weird

Keep Ruby Weird is happening in Austin on October 28th this year. It's a single-day, single-track conference put on by weird but nice folks like Caleb Thompson, Britt Ballard, Terence Lee, and Richard Schneeman.

Speakers this year include the wonderful Katrina Owen, Nick Means, Kylie Stradley, Justin Searls, Craig Kerstiens, Marty Haught, and Thomas Enebo.

If you're a new or old Rubyist, there's no better place to get a jam-packed day full of fantastic talks, people, food, and conversations than this weird little corner of the Ruby. As I'm saying this, there are only 24 tickets left, so... ORDER NOW! They're 200 dollars which is considerably cheaper than huge majority of conferences.

Outro

If you'd like to support this show, please take a few itty bitty seconds to leave a review on iTunes or Google Play.

I would also deeply appreciate your donations to help me produce the show in my free time without any sponsors. You can make recurring donations on Patreon or one-time donations on rubyfacets.com

Our dreamy little music was created by bensound.com and this episode was edited by Jamison Rabbe.

Thank you for listening and I'll be back next week with more Ruby Facets.

  continue reading

8 episodes

All episodes

×
 
Loading …

Welcome to Player FM!

Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.

 

Quick Reference Guide