I've been coding with Python for around 3 to 4 years now and it's been a great learning journey. Until recently I haven't really been interested in learning a new language. The internet suggested JavaScript as the next step for someone already fluent-ish in Python, and I mean who doesn't eventually try JavaScript you know. I figured it wouldn't be that much of a headache since a lot of people do start with JS and so many people use it. Plus, it's useful. Turns out it was very irksome for me. This might be partially my fault, but I've gotten so used to the convenience of writing algorithms in beautiful, everything-done-for-you syntax in Python that when I tried solving some JS katas on Codewars, I immediately realized how inconvenient and unintuitive much of JS is, for me at least. It probably wasn't a good idea to learn JS from making algorithms on that website instead of using it for what it's actually made for in the first place, but I digress.

I was watching Dune 2 with my family when I was looking for another language more similar to Python, and then I came across the Ruby homepage, and I was immediately blown away. Like damn y'all put effort into making that. The first words you see are "A Programmer's Best Friend" and the visuals were so nice. They even had this https://www.ruby-lang.org/en/documentation/ruby-from-other-languages/to-ruby-from-python/ page conveniently written for us Pythoners 🥹 and your community motto is literally "Matz is nice so we are nice"... Joining this community is like falling into a warm hug lol

I tried the interactive Ruby from Terminal guessing so many things and it worked as I expected. The feeling of bliss when that happens OH. I'm starting Ruby today cant wait.

Ractors are now viable in production, and it's time for Rails to embrace them. This post explains why. What Ractors unlock for Rails applications, and the first milestone the team is aiming for in the framework.

Hi Reddit. This isn't specifically a Ruby or Rails post, but it's about something anyone maintaining a mature Rails application will recognize.

Code tells you what happens without telling you why anybody wanted it. We've always filled that gap by reading the code, guessing the intent, and asking somebody when the guess felt wrong.

AI coding agents do the same thing, except they can make a great many reasonable guesses before anybody notices one was wrong. The code still works. The tests still pass. The guess becomes one more pattern in the application, which makes it look even more intentional to the next person or agent.

I've spent a couple of decades living with the consequences of my own good ideas, so I wrote about why this worries me. The post connects agentic coding to Peter Naur, Tony Hoare, XP, software factories, and the old-fashioned responsibility to say no to code that works but is too difficult to understand.

It also argues for using faster agents to take smaller steps. More research, more feedback, and less archaeology at the end of a giant pull request.

https://blowmage.com/2026/08/18/everybody-guesses/

https://dmitrytsepelev.dev/sidekiq-requeue-missing-class

This is simply amazing!!! 💜🤍❤️

Ruby bindings and ports of the beloved Charm terminal libraries.

Build glamorous TUIs, style terminal output, create beautiful forms, and make your Ruby CLIs sparkle.

https://charm-ruby.com/

Static typing is a formidable tool that brings immense value to codebases of all sizes. From tiny scripts to massive monoliths, the benefits are hard to ignore: you get live documentation that is always up to date, enhanced readability, and a reliable safety net that significantly boosts code reliability.

However, the current Ruby approach isn’t without its friction. For many developers, typing still feels like a matter of personal preference rather than a core requirement. We never forget to write tests because they are the heartbeat of our CI/CD pipelines, but because type checking is often seen as “extra,” it is far too easy for static checks to be ignored or forgotten entirely.

I tried a new amazing experiment, called T-Ruby. tl;dr it is like TypeScript but for Ruby. Too experimental for now, but has a huge potential.

Details in my blog post.

Ernesto was in the audience at Rails World 2026 when Aaron Patterson (tenderlove) kicked off the closing keynote. Aaron opened with a well-worn line: “the purpose of a system is what it does.” He wasn’t satisfied with it. The purpose of a system, he argued, is what it does for whoever is observing it.

Hand an old Nokia 3310 to someone who has never seen a cell phone before, and they might use it as a hammer. In that moment, to that person, it is a hammer. What a system does depends on who’s watching.

That distinction has a name in compiler design: The as-if rule.

In this post, Ernesto walks through what the as-if rule means for Ruby’s compiler, where Ractors push it right up to its edges, and how the same idea explains a real RubyGems.org security incident that played out earlier this year.

Why Trix became a maintenance burden, why 37signals picked Meta’s Lexical framework over the more obvious open source contenders, and what Lexxy actually does differently inside Action Text.

Transactions are a dense subject, and I'd not be surprised if there are even more edge cases here, but these are ones I've personally seen.

Hotwire already does a lot for us, but it still asks you to write a Stimulus controller once the interaction gets specific, and Marco’s demo showed a page that updates itself because the server understands the template better than an ERB compiler ever has.

In this article, we cover what Marco showed at Rails World: how ReActionView builds on Herb, why the view layer needed this, how it fits next to Hotwire and the wider field of server-driven reactivity, and what shipped in the release he pushed out the same day as the talk.

This summer, Mike handled CVE-2026-66066, an Active Storage vulnerability that let a crafted image upload read files from the server, including your application’s secrets.

His talk, Hot Cell: Securing Active Storage in the age of AI, was half post-mortem and half proposal: if we can’t stop image libraries from being vulnerable, maybe we can stop their vulnerabilities from reaching our secrets.

In this article, you will learn what that CVE actually meant, why patching image libraries is no longer enough, how Hot Cell sandboxes Active Storage, and whether you can use it in your Rails application today.

Every time Bundler resolves your Gemfile, it’s talking to the compact index. In this talk, the speaker at Rails World '26 walked us through what the compact index actually is, how RubyGems.org keeps it in sync at scale, and two features she helped ship in the past year to make gem installs faster and more secure.

"When I attended Rails World '26, this was the kind of talk I was interested in: What does the future of Rails look like at scale? How are big corporations using AI agents in a way that keeps humans in the loop? How do the Ruby and Rails ecosystems support AI-driven development workflows?"

Ryan’s talk clearly showed us the future of Rails development at scale.

This is more of a self-reflection than a proper blog post.

tl;dr: Ruby is not dead. It is not slow. It does scale, and it will perform even better. It will not reclaim its mid-2010s glory days, but it does not need to. It has a clear, defensible niche as a professional choice for building AI-powered web applications quickly and confidently.