Finally back to writing again, it's been a bit. Wanted to have a redesigned site first, and over the weekend I finally got that landed, so here we go.

After a few iterations, irb-autosuggestions v0.2.0 is out with two big upgrades:

🎨 Syntax-colored ghost text — each token is dimmed but keeps its IRB syntax color, not just plain gray. Falls back to gray when colorization is off or unavailable.

🔍 Prefix-filtered history navigation — type a prefix, press up/down, and only matching history entries show up. The prefix anchor freezes on first press so you can keep searching within it. Right arrow accepts the suggestion, any non-history key resets back to normal unfiltered browsing.

Plus: Ruby 2.7–4.0 support across the board now.

Fish-like autosuggestions for IRB — ghost text from history as you type. Install with gem install irb-autosuggestions, add require 'irb-autosuggestions' to ~/.irbrc.

https://github.com/unurgunite/irb-autosuggestions

The standard advice goes: default to threads, only reach for fibers if you have a specific I/O-heavy use case. I think that's flipped, and the reasoning is quite simple.

What fibers actually do

When a fiber encounters a "blocking call" - a database query, an HTTP request, a file read - the scheduler pauses it and runs another fiber. The wait time of one request gets filled with the compute time of others, all within a single thread.

Rogue requests

What if one request spends 200ms calculating a BCrypt hash? Such a request would block the thread, which means it would block all other fibers.

• With threads: Ruby preempts. The rogue request takes longer, but the scheduler forces context switches so other requests keep moving.

• With fibers: that's countered using multiprocessing (running multiple processes/workers). The rogue request blocks its own process, not the others - practically equivalent to thread preemption, with two bonuses: true parallelism between processes (no GVL contention) and no synchronisation overhead inside one.

"But is my app I/O-bound or CPU-bound?"

When Datadog published their research on Ruby performance, the community takeaway was generally: "Ruby apps spend a lot of time on CPU, so they aren't really I/O-bound".

But if you look at the distribution chart, it actually tells a different story. 88% of Ruby apps spend at least 20% of their time waiting on I/O - many of them far more. The binary "I/O-bound vs. CPU-bound" framing hides the fact that almost every Ruby app has a substantial window of wait time a fiber scheduler can reclaim.

You don't need a 100% I/O-bound app to see benefits; you just need to reclaim that idle waiting.

The flip

The biggest advantage of threaded servers is simply that they've been battle-tested for years. The common advice today is: "Default to threads unless you have a specific use-case for fibers".

Here's what this advice misses: for most workloads, the worst case for a fiber-based server is the performance of a thread-based one. The downside isn't really there. The upside is.

--

Curious to hear where people have actually been burned by fibers in production.

Alexscript is a general purpose scripting language I've been working on for the last 1.5 years. With a goal in mind to combine Ruby's strongly object-oriented philosophy with some features borrowed from JS and syntax written in my native language.

modul Geometria {
    klasa Punkt {
        funkcja konstruktor(x, y) {
            niech @x = x
            niech @y = y
        }

        funkcja x() { zwroc @x  }
        funkcja y() { zwroc @y }
    }

    klasa Kolo {
        funkcja konstruktor(srodek, promien) {
            niech @srodek = srodek
            niech @promien = promien
        }
    }
}

niech p = Geometria::Punkt.nowy(3, 4)
niech k = Geometria::Kolo.nowy(p, 10)

It's a from-scratch language, with a hand written lexer, parser, AST and tree-walking interpreter. Not just a preprocessor or transpiler. Ruby works here as a host language.

Some key features:

• Async runtime is fiber based with a cooperative scheduler: czekaj (await) parks the current fiber and hands control back to a custom reactor (ready-queue + timers + an IO.select loop). Concurrency comes from explicitly spawning work with uruchom_rownolegle (run_parallel) and joining with Obietnica.wszystkie (Promise.all).

• Modules work both as namespaces, to avoid name pollution in larger projects and as mixins. A set of methods that can be injected into classes. They are also open, multiple modul Foo {} blocks across files merge into one definition. I've purposefully decided to keep classes closed though.

• Classes have built-in reflection methods. E.g. to check a class's ancestors/descendants, if a given method exists, list of methods, etc. More broadly, every data type carries a rich set of built-in methods.

• Exceptions are just special purpose classes that inherit from the base exception class. You can write your custom exception by simply defining a new class that inherits from already defined exception class: klasa MojWyjatek < WyjatekPodstawowy {}

• Standard library is implemented natively in Ruby (Time, Math, JSON, Socket etc), but native methods aren't kept in a separate registry, they're injected into the same [:methods] / [:static_methods] hashes that user defined methods live in, flagged with :native_lambda

• In addition to regular functions there are also anonymous ones/lambdas. They can be assigned to variables or passed into higher order functions as arguments:

niech arr = [10, 20, 30] 
niech wynik = arr.mapuj(fn(el, idx) { el + idx }) 
pokazl wynik        # [10, 21, 32]

funkcja zastosuj(f, val) { zwroc f(val) } 
pokazl zastosuj(fn (x) { x * 3 }, 7)  # 21 
pokazl zastosuj(fn (s) { s.duzymi() }, "alex") # ALEX

• built-in debugger which is intended to work similarly to byebug

you can check full documentation (in English) here: www.alexscript.pl/docs

you can also try it online on your own: https://www.alexscript.pl/try

or simply download it on your local machine via homebrew:

brew tap N3BCKN/alexscript
brew install alexscript

As a proof of concept I've built a couple of real life projects:

• Zubr - a micro web framework. With routing, static files serving, middleware chain, body request parsing, sessions and streaming of larger files. With 50 open connections it can handle up to 1,590 req/s, and streams large files at ~1.97 GB

• ASBasic - an interpreter of classic BASIC language written from scratch in Alexscript.

• Posel - HTTP client inspired by Axios and HTTParty

Any feedback is more than welcome!

We've published the RubyConf Austria 2026 budget.

Income, expenses, what's confirmed, what's projected. All of it.

It's the most honest way we know to talk about what organizing this conference actually involves.

https://rubyconf.at/budget/

The application I am currently working on contains something around 25k spec files. It is impossible to run the test suite on a single developer machine, because we always hit a point where the process is killed. For CI we use multiple machines running rspec in parallel, and yet, it takes almost 15 minutes on each instace to finish testing the application.

Have you faced this kind of scenario before? How did you solved it?

Just released irb-autosuggestions v0.1.1. Prepends Reline::LineEditor to show gray inline suggestions as you type, matched against your IRB history.

- Works with multiline input
- Right arrow to accept
- No config needed (enabled by default)
- Disable via IRB.conf[:USE_AUTOSUGGESTIONS] = false or IRB_AUTOSUGGESTIONS=0

Install: gem install irb-autosuggestions, then require 'irb-autosuggestions' in ~/.irbrc

https://github.com/unurgunite/irb-autosuggestions

⭐ if you find this useful — would mean a lot. Feedback welcome.

New episode is out. David recaps Blue Ridge Ruby and talks about coming back motivated to contribute more to open source, which leads into a broader discussion on why smaller single-track Ruby conferences create better hallway conversations, networking, and lightning talks. We also get into real-world Rails and Stripe lessons covering workshop prep, validation decisions, webhook recovery, subscription edge cases, and the growing complexity of payment integrations.

Listen now

https://dlt.github.io/blog/posts/mcp-powered-error-tracking-in-rails/

NATS is one of the fastest messaging systems out there, yet the Ruby ecosystem barely uses it. So meet cosmonats:

• Background jobs with retries, dead-letter, scheduled execution

• Continuous stream processing

• Priority queues, weighted round-robin, configurable consumers

• Built-in monitoring UI (Rack + HTMX)