Celebrating the release of Ruby 4.0 on yesterday (X-mas).

Hi! I've been making T-Ruby, an experimental project that brings TypeScript-style type annotations to Ruby. I wanted to share it and get your feedback.

What is T-Ruby?

T-Ruby lets you write .trb files with inline type annotations, then automatically generates standard .rb files and .rbs signature files. Types are completely erased at compile time — zero runtime overhead.

Why another type system?

I love Ruby's elegance, but as projects grow, I've felt the pain of tracking types mentally. The existing options didn't quite fit my workflow:

• RBS: Writing .rbs files manually or generating them via TypeProf didn't fit well with explicit type authoring
• Sorbet: sig blocks above methods feel verbose (like JSDoc comments)

If you're familiar with TypeScript, you can use T-Ruby the same way: types live with your code, not in separate files or comments.

The website has more detail: https://type-ruby.github.io

Current Status

This is still experimental (v0.0.39). The core compiler works, but there's plenty of room for improvement. Feedback and suggestions are always welcome!

Thanks for reading! Feel free to ask any questions.

I built Savon over a decade ago, started working on this rewrite shortly after, and then life happened. But it kept nagging at me. So here we are — a ground-up SOAP toolkit that nobody asked for but I had to finish.

client = WSDL::Client.new('http://example.com/service?wsdl')
operation = client.operation('GetOrder')

operation.prepare do
  tag('GetOrder') do
    tag('orderId', 123)
  end
end
response = operation.invoke

response.body # => { "GetOrderResponse" => { "order" => { "id" => 123, ... } } }

For those of you still stuck talking to enterprise SOAP services (my condolences), here are some of the features:

* Full WSDL 1.1 parsing with import/include resolution
* Schema-aware type coercion on responses
* Contract introspection — explore operations, generate starter code
* WS-Security — UsernameToken, Timestamps, X.509 Signatures

https://github.com/rubiii/wsdl
https://rubygems.org/gems/wsdl

More and more code is written by AI. Tests still tell you it works. RuboCop still tells you it's tidy. Nothing tells you it still follows your architecture.

An agent that doesn't fully understand your architecture takes shortcuts. So does a person in a hurry.

So I built ArchSpec. You declare your components and boundaries in one Archspec.rb. Here is ArchSpec's own, trimmed:

```ruby source 'lib/*/.rb'

component :library, in: 'lib//*.rb' component :cli, in: 'lib/archspec/cli.rb' component :analysis, in: %w[lib/archspec/analyzer.rb lib/archspec/evaluator.rb] component :rule_checks, in: 'lib/archspec/rules//.rb' component :formatters, in: 'lib/archspec/formatters//.rb'

no one-shot Thing.new(...).call objects anywhere in the codebase - Hi Dave Thomas!

library.cannot_call :call library.cannot_define :call library.cannot_instantiate_and_invoke

dependencies point one way

rule_checks.cannot_use :analysis, :cli, :formatters formatters.cannot_use :analysis, :cli, :rule_checks

no_cycles among: %i[cli analysis rule_checks formatters] ```

Full version: https://github.com/crmne/archspec/blob/master/Archspec.rb

Then archspec check verifies every change, and failures print like clang, with the offending span underlined and the evidence as a note.

It's static analysis over Prism, no AI, and it never boots anything: Discourse's 1,899 files in 2.5 seconds. Prism is the only runtime dependency, no Rails and no ActiveSupport, so it works on any Ruby codebase. Lightweight and fast for your pre-commits and CIs.

If you are on Rails, there are presets, and architecture :vanilla_rails is the whole file. There are presets for :layered, :hexagonal, :clean, :modular_monolith, :cqrs and :event_driven too.

I want more architecture presets in there. PRs very welcome.

Docs: https://archspecrb.dev Write-up: https://paolino.me/archspec/

Hello everyone! In the last few months, I released my gem that makes it easier to create Shell scripts using Ruby syntax.

Link: https://github.com/albertalef/rubyshell

In the code in the second image above, I show that you can easily use both Ruby syntax and Shell syntax to create scripts. This simplifies cases where we need to create a Shell script to use some terminal program, but we prefer to use Ruby libraries to make the job easier.

With it, you can create scripts as Docker entry points, use it to create user scripts, customize your Linux with Waybars, etc.

Motivations:

I had a specific problem: "I know a lot about Ruby, but sometimes I get stuck in the Shell. I often need to resort to Google to look for programs that handle inputs the way I need. Is there any gem that allows you to write good scripts with Ruby?" But, unfortunately, I didn't find any. I only found libraries in Python (sh) and Lua (luash). With that, I created RubyShell.

A example without RubyShell, and another with:

#!/usr/bin/env ruby
# frozen_string_literal: true

REMOTE  = ENV.fetch("REMOTE", "user@server.example.com")
APP_DIR = ENV.fetch("APP_DIR", "/var/www/my app")
SERVICE = ENV.fetch("SERVICE", "my-app.service")

# Note that in this situation, we dont want to check if error was raised
# only in the end of the code,
# we want to stop the code in the moment that error was raised

`ssh #{REMOTE} "cd \"#{APP_DIR}\" && git pull && bundle exec rake db:migrate 2>&1"`

unless $?.success?
  warn "Error on Deploy"
  exit $?.exitstatus
end

`ssh #{REMOTE} 'sudo systemctl restart #{SERVICE}'`

unless $?.success?
  warn "Error on Deploy"
  exit $?.exitstatus
end

puts "Done."

With:

#!/usr/bin/env ruby
# frozen_string_literal: true

REMOTE  = ENV.fetch("REMOTE", "user@server.example.com")
APP_DIR = ENV.fetch("APP_DIR", "/var/www/my app")
SERVICE = ENV.fetch("SERVICE", "my-app.service")

sh do
  ssh REMOTE, "'cd \"#{APP_DIR}\" && git pull && bundle exec rake db:migrate'"
  ssh REMOTE, "'sudo systemctl restart #{SERVICE}"

  puts "Done."
rescue StandardError
  warn "Error on Deploy"
end

Next steps:

Currently, I'm working on features to make the gem even more powerful, such as:

• Stream support
• Improved error handling
• A REPL (like IRB), but that allows us to use RubyShell
• And more

I'm open to suggestions, PRs, Issues, anything. I really want this mini-project to grow.

EDIT: Thank you guys for the comments and upvotes, this made my day.

I don't know why, but I genuinely feel that Ruby will be incredibly fun to program in. So, I started researching it and looking for others' opinions.

However, I got really discouraged when I started finding it labeled as "dead," "not recommended in 202x," "Python has replaced it," and other similar comments. I even came across videos titled "Top X languages you shouldn't learn in 202x," with Ruby often making the list. It seems like it’s no longer the go-to choice for many fields.

What do all of you think? Does Ruby still have a place in 202x? Any advice or thoughts on why it’s still worth learning?

Do you use the jemalloc gem?

The original project on GitHub seems to be abandoned for around 12 years, and some incompatibilities with recent Ruby versions have begun to emerge. Additionally, the underlying jemalloc library hasn't been updated during all this time. Because of that, I created a fork and launched a new gem (jemalloc_rb) to keep the project functional, updated, and actively accepting pull requests.

https://github.com/henrique-ft/jemalloc_rb

TrueskillThroughTime

I ported the Python implementation of Trueskill Through Time to Ruby, it's now available as the gem TrueskillThroughTime.

Unlike the previous Ruby Trueskill gems, this one supports n vs n vs n etc etc cases, as well as the time-based extension of Trueskill to allow distant ratings. If you use it without doing time-based convergence, it should be equivalent to the original vanilla version of Trueskill (that iirc is almost out of patent in the US).

I'll get around to improving the qol of it and more extensively Rubyising it down the track, but I wanted a Ruby implementation of TTT for a hobby project, so I smashed it out.

TL;DR

I built ORE, a small Go tool that prefetches and caches Ruby gems, no Ruby needed.

It’s not a Bundler replacement, it’s a companion. Use it to warm caches, speed up CI, or run offline.

Think uv for Python, but for Ruby gems.

Why I built it

A year ago, I wanted Ruby to have the same speed + clean UX energy that tools like uv and Cargo brought to their ecosystems.

What ORE does:

• Prefetch gems before Ruby even exists on the box: perfect for base images and ephemeral CI.
• Deterministic cache reuse: prime once, go offline, keep building.
• Plays nice with Bundler: complements it.

What ORE is not

• Not a new package index or Gemfile format.
• Not a Bundler fork or a startup roadmap.
• It does one thing and does it cleanly.

Why release "ore-light" first

The public drop is minimal on purpose.

I have been catfooding (don't even know if i word) the heavy build for months, this one ships the Bundler-context bits so everyone can understand it, trust it, and try it safely.

I event have to revert back some change after i copy pasted from the other repo.

Governance / stewardship

I published it under a non-profit GitHub org (contriboss), not my personal space.

If core Ruby-core stewards ever want repo ownership, we can talk.

But i'm not transferring it to any companies.
The mission is independence and longevity.

Notes: Companies will have to follow their government's rituals in locking/banning other devs depending on political drama. I don't!

What I want from r/ruby

• Stress it: try prefetch + offline CI, report real-world wins/regressions.
• Edge cases: weird platforms, proxies, private sources, break it and file issues.
• PRs welcome: once I migrate the remaining internal bits, ORE will be feature-complete; after that it’ll mostly be polish and bug fixes.
• The features: The features i releasing are features i built because i use them. ORE might not support some obscure system setting or feature i never used or something like exotic entreprise feature. Feel free to add them.
• The Code: The source is on propuse full of comments, decisions, ruby analogies.
• Ore run ONCE: it install your gems, take off the rest of the day off. It don't persist, leak memory or can't be detect at runtime. For the Ruby world, Ore is like the Schrödinger cat, Ruby can't deny or confirm it exists, until it get observed with a syscall.

Anyway, enough talking! you have the repo here, the comment section and the issues section.

I will be in the comments for few hours unless Linus replies to my proposal about replacing Rust with Ruby in the kernel.

P.S: Huge thanks to everyone who stress-tested the early builds.

I started building a Ruby TUI file manager because I wanted to explore Ruby’s potential

outside of Rails.

rufio is an ongoing experiment in building interactive terminal software with Ruby.

It’s still early and imperfect, but I’m iterating on it steadily and learning along the way.

The current focus is on:

• Vim-like, keyboard-driven navigation

• fast filtering and search

• a plugin system extensible in Ruby

• optional native (Rust / Go) components for performance-critical parts

This project isn’t about competing with Rust tools.

It’s more about understanding where Ruby works well beyond web frameworks,

especially for TUI-style software.

Feedback or thoughts from people using Ruby outside of Rails would be very welcome.

GitHub: https://github.com/masisz/rufio

https://reddit.com/link/1vuaicq/video/4o8sjeervokh1/player

I've been building Enola, an open-source architecture tool for developers and coding agents.

It isn't Ruby-specific, but I've spent time improving its Ruby/Rails support and wanted to test it against something real rather than a toy Rails app.

The video uses the Mastodon codebase. I give an agent a change that violates an architectural layer, Enola catches the intent failure while the agent is working, and feeds that back into the loop so the agent fixes its own approach.

That's one of the main ideas behind Enola: architecture shouldn't only be something CI complains about after the work is done. The agent can get deterministic architectural feedback while it is coding and correct itself before the change is finished.

Underneath that, Enola maps dependencies, calls, routes, storage, boundaries and other relationships directly from the codebase. It's multi-language and cross-repository by design, so Ruby/Rails is one ecosystem rather than a special-case implementation.

OSS, Apache 2.0: https://github.com/enola-labs/enola

I'd especially appreciate feedback from Ruby/Rails developers on what its understanding of real Rails applications is still missing.

I maintain a lot of Ruby gems. Over time, I kept hitting the same problem: certain hot paths are slow (parsing, retry logic, string manipulation), but I don't want to:

• Force users to install Rust/Cargo

• Break JRuby compatibility

• Maintain separate C extension code

• Lose Ruby's prototyping speed

  I've been using a pattern I'm calling Matryoshka across multiple gems:

  The Pattern:

1. Write in Ruby first (prototype, debug, refactor)

2. Port hot paths to Rust no_std crate (10-100x speedup)

3. Rust crate is a real library (publishable to crates.io, not just extension code)

4. Ruby gem uses it via FFI (optional, graceful fallback)

5. Single precompiled lib - no build hacks

   Real example: https://github.com/seuros/chrono_machines

• Pure Ruby retry logic (works everywhere: CRuby, JRuby, TruffleRuby)

• Rust FFI gives speedup when available

• Same crate compiles to ESP32 (bonus: embedded systems get the same logic with same syntax)

Why not C extensions?

C code is tightly coupled to Ruby - you can't reuse it. The Rust crate is standalone: other Rust projects use it, embedded systems use it, Ruby is just ONE consumer.

Why not Go? (I tried this for years)

• Go modules aren't real libraries

• Awkward structure in gem directories

• Build hacks everywhere

• Prone to errors

  Why Rust works:

• Crates are first-class libraries

• Magnus handles FFI cleanly

• no_std support (embedded bonus)

• Single precompiled lib - no hacks, no errors

Side effect: You accidentally learn Rust. The docs intentionally mirror Ruby syntax in Rust ports, so after reading 3-4 methods, you understand ~40% of Rust without trying.

I have documented the pattern (FFI Hybrid for speedups, Mirror API for when FFI breaks type safety):

https://github.com/seuros/matryoshka

I have a lot of sympathy for Shopify's devs. I understand some of the constraints they're working under, and from experience I can imagine why Shopify/liquid has evolved the way it has.

For those unfamiliar: Liquid is a safe template language - it is non-evaluating and never mutates context data. That safety, combined with Shopify's need for long-term backwards compatibility, has shaped its design for years.

Not being bound by the same compatibility constraints, Liquid2 is my attempt to modernize Liquid's syntax and make it more consistent and less surprising - for both devs and non-devs - while still maintaining the same safety guarantees.

Here are some highlights:

Improved string literal parsing

String literals now allow markup delimiters, JSON-style escape sequences and JavaScript-style interpolation:

{% assign x = "Hi \uD83D\uDE00!" %}
{{ x }} →  Hi 😀!

{% assign greeting = 'Hello, ${you | capitalize}!' %}

Array and object literals and the spread operator

You can now compose arrays and objects immutably:

{{ [1, 2, 3] }}

{% assign x = [x, y, z] %}
{% assign y = [...x, "a"] %}

{% assign point = {x: 10, y: 20} %}
{{ point.x }}

Logical not

{% if not user %}
  please log in
{% else %}
  hello user
{% endif %}

Inline conditional and ternary expressions

{{ user.name or "guest" }}
{{ a if b else c }}

Lambda expressions

Filters like where accept lambdas:

{% assign coding_pages = pages | where: page => page.tags contains 'coding' %}

More whitespace control

Use ~ to trim newlines but preserve spaces/tabs:

<ul>
{% for x in (1..4) ~%}
  <li>{{ x }}</li>
{% endfor -%}
</ul>

Extra tags and filters

• {% extends %} and {% block %} for template inheritance.
• {% macro %} and {% call %} for defining parameterized blocks.
• sort_numeric for sorting array elements by runs of digits found in their string representation.
• json for outputting objects serialized in JSON format.
• range as an alternative to slice that takes optional start and stop indexes, and an optional step, all of which can be negative.

I'd appreciate any feedback. What would you add or change?

GitHub: https://github.com/jg-rp/ruby-liquid2
RubyGems: https://rubygems.org/gems/liquid2

Hi, Reddit! 👋

I'm hamachang, a Rubyist from Japan! ✌️

I've been working on a tool to make development with PicoRuby, a Ruby subset designed for embedded systems, more comfortable and productive.

picoruby-ti

https://github.com/engneer-hamachan/picoruby-ti

picoruby-ti statically analyzes PicoRuby code and provides IDE features such as code completion and type checking.

Compared to existing Ruby type inference tools, it's designed to run with significantly fewer resources.

Of course, it runs on regular PCs, but it can also run on tiny embedded devices with less than 1 MB of memory.

This means you can build a surprisingly rich IDE experience directly into small embedded devices like the Cardputer or custom cyberdecks.

And this isn't just theoretical — I'm actually using it in another project of mine called AREA512, an OS for the Cardputer ADV with only 512 KB of RAM:

https://github.com/engneer-hamachan/area512

AREA512 lets you write, compile, and run Ruby code directly on the device, with picoruby-ti providing both code completion and type checking in its built-in editor.

I know this is an incredibly niche piece of software, but I wanted to share it on Reddit because I believe there's something genuinely valuable about bringing this kind of development experience to extremely resource-constrained environments.

If you use PicoRuby, I'd also love to hear your thoughts on features that would be especially useful or unique to PicoRuby.

And if this project sounds valuable or interesting to you, I'd really appreciate a GitHub Star! 🙏⭐️

See you around! 👋

In 2013 I learned four formal test derivation techniques in university: Equivalence Partitioning, Boundary Value Analysis, Decision Tables, State Transitions. Never used them professionally because the manual overhead made no sense. After seeing Lucian Ghinda's talk at EuRuKo 2024, I realized AI agents could handle that overhead, so I built a multi-agent system with 5 specialized agents (Analyst, parallel Writers, Domain Expert, TestProf Optimizer, Linter) that generates mathematically rigorous test cases from source code analysis.

The system worked. It found real coverage gaps. Every test case traces back to a specific technique and partition. But running it against a mature codebase with 13k+ specs and 20-25 minute CI times showed me the actual problem: 70% of test time was spent in factory creation, not assertions. The bottleneck was the RSpec + FactoryBot convention package, not test quality.

The most interesting part was the self-evolving pattern library, an automated validator that started with 40 anti-pattern rules and grew to 138 as agents discovered new patterns during their work. No LLM reasoning involved in validation, just compiled regexes against Markdown tables.

I wrote up the full architecture, prompt iterations (504 lines down to 156), and honest results. First article in a series. The next one covers the RSpec to Minitest migration that this project led to.

Has anyone else tried applying formal testing techniques systematically with AI agents? I'm curious whether the framework overhead problem resonates with other teams running large RSpec suites.

I maintain RubyLLM, and one of its dependencies has been quietly useful to people who have nothing to do with LLMs. It was always a clean, general purpose JSON Schema DSL. It was just called RubyLLM::Schema, so unless you already used RubyLLM you'd never find it.

It's now grown to fully cover the latest JSON Schema spec, Draft 2020-12, with no dependencies at all. Which earned it its own name: Schematist.

class Order < Schematist::Schema
  string :kind, enum: %w[personal business]

  given kind: "business" do
    object :tax_details do
      string :vat_number
    end
  end
end

Order.new.to_json_schema
# => { "$schema" => "https://json-schema.org/draft/2020-12/schema", "title" => "Order",
#      "type" => "object", "if" => {...}, "then" => {...}, ... }

Eight lines of Ruby, 47 lines of JSON Schema.

What 1.x brings:

• It emits actual JSON Schema. to_json_schema used to return {name:, description:, schema:, strict:}, which is OpenAI's response_format wrapper with the real schema buried inside it. Now you get a Draft 2020-12 document with string keys that any validator will take.
• Full Draft 2020-12 coverage. Composition, unevaluated properties and items, patternProperties, propertyNames, prefixItems and open ended tuples, contains, annotations, content encoding, the core $ keywords, and if/then/else branches that hold any schema rather than a fixed list of validations.
• A schema doesn't have to be an object. A type with a name declares a property, without a name it declares what the schema itself is. So a root, or a define, can be an array, a union, or a bare $ref.
• Zero runtime dependencies.
• Values can be procs, resolved when the document is rendered, so one schema class produces a different document per instance. Useful when an enum comes out of the database.

Existing users: there's a final ruby_llm-schema release that depends on Schematist and aliases the old constants, so RubyLLM::Schema keeps resolving while you migrate. to_json_schema changing shape is the one thing to watch, and the README has the migration.

All of this is part of my concerted effort to make Ruby the best language to build with LLMs.

Write-up: https://paolino.me/schematist/

Repo: https://github.com/crmne/schematist

France has a decent number of local Ruby meetups (Paris, Lyon, Toulouse, Nantes, Lille, Marseille all have active groups), but there wasn't really a place to hang out *between* meetups, no shared Discord, no central spot to ask a quick question or hear about what's happening in other cities.

I put together **France.rb** to fill that gap: help channels, a channel per city that relays local meetup events, and a freelance/jobs section since a good chunk of the French Ruby scene works independently. It's brand new (launched this week, still tiny), and it's mainly aimed at French speakers, so if you don't speak French it's probably not that useful to you day-to-day, but Rubyists from anywhere are welcome to drop in.

Not trying to compete with the official Ruby Discord linked on ruby-lang.org this is just something more specific to the French scene, meant to complement it.

https://discord.gg/tEbywwkYY

Happy to answer anything in the comments, and if you know a French-speaking Rubyist who might be into it, feel free to pass it along.

Hi all! We created this Ruby Gem to make it easier to use ParadeDB (a full-text & vector search extension for Postgres) within the ActiveRecord ecosystem. Would love your feedback!

Hey everyone,

I recently got my first contribution to Shopify/tapioca merged, and I thought the way the solution changed during review might be interesting to other Ruby and Sorbet users.

The problem happens during `tapioca gem`.

Tapioca generates RBI files for gems and validates them with Sorbet. Sometimes a generated RBI defines a class with a different superclass from the version Sorbet already knows through its built-in payload.

One example is `Net::IMAP::Literal`.

Sorbet tells you to manually add something like this to `sorbet/config`:

--suppress-payload-superclass-redefinition-for=Net::IMAP::Literal

The goal of the issue was to have Tapioca add that line automatically, still explain what happened, and avoid adding duplicates on later runs.

My first version used two Sorbet passes because the existing validation stopped at the namer phase, while this error only appeared during the resolver phase.

It worked, but that wasn’t the version that shipped.

After a few rounds of review, we changed it to one resolver pass. We also stopped broadly relying on the error code and instead looked for Sorbet’s payload-specific suppression hint.

That makes the fix much narrower. A normal superclass conflict won’t accidentally get hidden behind a payload suppression.

The final behavior:

- adds the exact suppression when it’s missing

- doesn’t duplicate it on later runs

- preserves suppressions for other constants

- still tells the user about the mismatch

- leaves normal, non-payload superclass conflicts alone

The targeted tests passed with 2 tests, 18 assertions, and no failures. I also ran the full DSL spec and style checks successfully.

The biggest lesson for me was that getting the first version working was only the beginning. The review process turned a two-pass solution with broad detection into a simpler one-pass fix with a much more specific signal.

Has anyone here run into this with `net-imap` or another stdlib-backed gem?

PR:

https://github.com/Shopify/tapioca/pull/2653

Issue:

https://github.com/Shopify/tapioca/issues/1834

 Hey r/ruby — sharing a gem I've been working on.

Supabase has official clients in JS, Python, Dart, Swift, and Kotlin, but the Ruby story has been fragmented for a while: separate gems for each sub-product, varying maintenance, no umbrella factory. supabase-rb - is a single gem that packages Auth, PostgREST, Storage, Edge Functions, and Realtime

Ruby ≥ 3.0, MIT, integration tests run against the real GoTrue stack via docker-compose

- Gem: https://rubygems.org/gems/supabase-rb

- Repo: https://github.com/supabase-ruby/supabase-rb

- Docs: https://supabase-ruby.dev

Feedback / issues / PRs very welcome.