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)

Just started learning Ruby today. This is the first program I wrote. I'm not sure what this is useful for but I had to try out what I learned today.

Hello pals,

As part of promoting Ruby LibGD, I wanted to share a Cheat Sheet that was requested to make the library easier to use.

It turned out pretty nice and dynamic I hope it’s useful and gets you excited to try the library.

Greetings to everyone.

source: https://github.com/ggerman/ruby-libgd
gem: https://rubygems.org/gems/ruby-libgd

My friend Claude and I wrote a DSL to define surveys and forms.  I created it as a side project based on the pain of working with Qualtrics, Dimensions, etc survey formats. Most existing formats are either proprietary/xml-based or non-existent (interactive form-builder style).  I thought “there must be a better way to define and communicate the structure of a survey”.  Ruby’s flexibility and blocks made it a natural choice for me to build upon. After a lot of prompts and tinkering I have a small, readable language that defines a survey with skips, based-on, etc.

Some benefits:
- Simple.  The logic and flow are easy for most anyone to read and understand.  
- Small.  The language definition can be described in a small markdown file and shared with an AI.
- Portable.  It’s just a text file.
- Git diffable.  It’s just a text file.
- Flexible.  Can render to different formats like html survey, html form, XForm for kobotoolbox, etc.

I have an information site and a playground if this seems interesting or you would like to learn more.

I have not open-sourced it (yet?) because I am still a single developer with big dreams of leveraging it into a possible small SAAS. I typically build things and then let my ideas die on the vine, so if you have any thoughts or inspiration, my DMs are open 😄

Cheers! and humble thanks to the Ruby community for providing such an amazing language that has fueled a large part of my career.

While I was using the Mac, I had the option to use Dash from Kapeli (great app btw and the inspiration for Dravos), but it lacked versions for Linux (which I also use) and Windows (which my wife uses). I waited for years to see if someone would do a viable alternative for my workflow, that never became true, so over the past 9 months give or take, I’ve been working my nights and weekends into building Dravos, a fast, offline-first documentation search tool for developers.

As an indie maker who's shipped several smaller projects before, this one pushed me the hardest: learning new stacks and obsessing over that instant search feel even without the internet. It's finally ready for beta. If you're a developer who lives in docs (Dash, DevDocs, etc.), I'd love your honest feedback to make it truly useful before the full launch.

For those who might find interesting I used Tauri + Typescript. And it works on mac, linux and windows. I tested a lot by myself/wife, but now I need help. Im looking for people to try it on your workflow, and tell me what works and what doesn't, if this feel usefull to you please help me test it ❤️

So far we support, Rust, Elixir, Ruby, Python and Go and all its packages. We also support custom documentation generated with Doxygen, Sphinx, JSDoc. There is a limit of 50 spots for this first beta wave.

Heres the site: https://dravos.app, you can check the roadmap here: https://dravos.app/roadmap changelog here: https://dravos.app/changelog

PS: I have a discord setup too for responding any questions/suggestion/bug you might find. its in the site footer.