
Matz released Spinel, an experimental ahead-of-time compiler for Ruby that produces standalone native binaries. The numbers from the official benchmarks are hard to ignore: on Conway's Game of Life it runs 86.7x faster than miniruby. That kind of gap is not a tuning win. It comes from a fundamentally different execution model.

Standard CRuby and YJIT work by interpreting or JIT-compiling Ruby at runtime. Every time a variable is used, the VM has to ask what type it is before it can decide what to do with it. Those repeated runtime checks are a large part of why interpreted Ruby has a performance ceiling.

Spinel takes a different path. It runs offline, before the program executes:

1. Parse the source with Prism
2. Run whole-program analysis across all files simultaneously
3. Infer static types from the analysis
4. Generate optimized C code from the typed AST
5. Compile that C with Clang or GCC into a standalone native binary

The result is a binary that starts instantly and needs no Ruby runtime. Because types are resolved at compile time, the runtime checks that slow down CRuby are gone entirely.

The benchmark table below is from the [official Spinel repository](https://github.com/matz/spinel). Lower time is better.

```text
BENCHMARK            SPINEL    MINIRUBY    SPEEDUP
life (Conway's GoL)   20 ms    1,733 ms     86.7x
ackermann              5 ms      374 ms     74.8x
mandelbrot            25 ms    1,453 ms     58.1x
fib (recursive)       17 ms      581 ms     34.2x
nqueens               10 ms      304 ms     30.4x
tarai                 16 ms      461 ms     28.8x
tak                   22 ms      532 ms     24.2x
matmul                13 ms      313 ms     24.1x
sudoku                 6 ms      102 ms       17x
partial_sums          93 ms    1,498 ms     16.1x
fannkuch               2 ms       19 ms      9.5x
sieve                 39 ms      332 ms      8.5x
fasta (DNA seq gen)    3 ms       21 ms        7x
```

Every benchmark shown is compute-heavy and branchy, exactly the kind of workload where dynamic type dispatch costs the most. Spinel's smallest win is 7x on DNA sequence generation, and its biggest is 86.7x on a grid simulation with tight inner loops.

The trade-off is scope. Static analysis only works when types can be fully inferred at compile time. Ruby's dynamic features like `method_missing`, `eval`, `define_method` with runtime strings, and monkey-patching are either unsupported or limited. Spinel targets the subset of Ruby that behaves predictably, which covers a lot of algorithmic code but not a general Rails application.

Spinel does not replace CRuby. It is a proof of concept for a different point in the design space: what happens if you take Ruby syntax, run it through a whole-program compiler, and hand the result to GCC. The answer, for the right class of programs, is that you get native speed with Ruby ergonomics.

The repository is at [github.com/matz/spinel](https://github.com/matz/spinel).


Spinel: The Compiled Ruby


Ruby 3.3 adopted Prism as its default parser, and it comes with a clean API for traversing Abstract Syntax Trees. That means you can build robust code analyzers without needing to master RuboCop's complex DSL or write your own parser from scratch.

The core primitive is `Prism::Visitor`. You subclass it and define `visit_*` methods for the node types you care about. Prism calls them as it walks the tree, and `super` tells it to continue the traversal down into child nodes.

```ruby
class YourVisitor < Prism::Visitor
  def visit_call_node(node)
    # node.name, node.receiver, node.arguments
    super # continue traversal
  end

  def visit_def_node(node)
    # node.name, node.location.start_line
    super
  end

  def visit_symbol_node(node)
    # node.value
    super
  end
end

Prism.parse(source).value.accept(YourVisitor.new)
```

To see this in practice, here is a dead code finder for private methods. It tracks every method call across a file and every private method definition, then compares the two sets at the end.

```ruby
require "prism"

class DeadCodeFinder < Prism::Visitor
  attr_reader :private_methods, :calls

  def initialize
    @private_methods = {}
    @calls = []
    # tracks whether we've passed the 'private' keyword
    @in_private = false
  end

  def visit_call_node(node)
    # flip flag when we hit the 'private' keyword
    @in_private = true if private?(node)
    # collect every method call in the file
    @calls << node.name
    super
  end

  def visit_symbol_node(node)
    # catch before_action :method, passed as symbol, not a call
    @calls << node.value.to_sym
    super
  end

  def visit_def_node(node)
    # ignore public methods
    return super unless @in_private
    # register private method + line
    @private_methods[node.name] = { line: node.location.start_line }
    super
  end

  private

  def private?(node)
    # 'private' alone, not 'object.private'
    node.name == :private && node.receiver.nil?
  end
end
```

The `visit_symbol_node` hook matters here because Rails patterns like `before_action :set_report` pass method names as symbols, not calls. Without it, `set_report` would incorrectly appear as dead code.

Consider this feature spread across three files, where several private methods are defined but never actually called:

```ruby
# app/controllers/reports_controller.rb
class ReportsController < ApplicationController
  before_action :set_report

  def index
    @reports = ReportService.new(current_user).call
  end

  private

  def set_report
    @report = Report.find(params[:id])
  end

  def format_csv(data)
    # never called
    data.map(&:to_csv).join("\n")
  end
end
```

```ruby
# app/models/report.rb
class Report < ApplicationRecord
  belongs_to :user

  scope :completed, -> { where(status: :completed) }
  scope :archived,  -> { where(status: :archived) }

  private

  def calculate_totals
    # never called
    line_items.sum(:amount)
  end
end
```

```ruby
# app/services/report_service.rb
class ReportService
  def initialize(user)
    @user = user
  end

  def call
    fetch_orders
  end

  private

  def fetch_orders
    @user.orders.completed
  end

  def build_summary(orders)
    # never called
    orders.group_by(&:status)
  end

  def send_alert(message)
    # never called
    AdminMailer.alert(message).deliver_later
  end
end
```

Running the visitor across all files is a two-pass process: collect every call and every private definition in one sweep, then subtract the called ones.

```ruby
files = Dir.glob("app/**/*.rb").sort

all_calls = []
per_file = {}

files.each do |file|
  # parse file into AST
  result = Prism.parse(File.read(file))

  finder = DeadCodeFinder.new
  # walk the tree, triggering visit_* methods
  result.value.accept(finder)

  # accumulate all calls across files
  all_calls.concat(finder.calls)
  per_file[file] = finder.private_methods
end

# remove duplicates before cross-file comparison
all_calls.uniq!

per_file.each do |file, methods|
  dead = methods.reject { |name, _| all_calls.include?(name) }
  next if dead.empty?

  puts file
  dead.each { |name, meta| puts "  line #{meta[:line]}: #{name}" }
end
```

The output is a precise list of dead private methods with their file paths and line numbers, ready to delete or investigate.

```text
app/controllers/reports_controller.rb
  line 14: format_csv

app/models/report.rb
  line 9: calculate_totals

app/services/report_service.rb
  line 16: build_summary
  line 21: send_alert
```

This scales to thousands of files without modification. Prism parses fast enough that running this kind of analysis on a large Rails codebase takes seconds, not minutes. And because you control exactly which node types you visit and what you collect, adapting this pattern to other questions like unused constants, undocumented public methods, or call chains is straightforward.


Prism for Massive-Scale Code Analysis


Ruby is usually associated with web development, but the Ruby ecosystem has room for much leaner runtimes too. One of them is PicoRuby, a Ruby implementation designed to run on microcontrollers and other highly constrained devices.

According to the official documentation, PicoRuby can run with 128KB of RAM or less. That makes it a very different proposition from standard CRuby and a strong fit for boards where every kilobyte matters.

That smaller footprint comes from deliberate trade-offs. PicoRuby ships with fewer native modules and a simplified garbage collector, favoring minimal memory usage over raw execution speed.

To compare the trade-off in practice, I ran a small Fibonacci benchmark and measured resident memory directly from `/proc/self/status` on Linux. Because PicoRuby does not include the standard `Benchmark` gem, the script reads both time and memory usage manually.

```ruby
def memory_kb
  # Direct access to Linux process status
  # PicoRuby does not ship with the standard Benchmark gem
  File.foreach('/proc/self/status') do |line|
    if line.start_with?('VmRSS:')
      digits = ''
      line.each_char { |char| digits += char if char >= '0' && char <= '9' }
      return digits.to_i
    end
  end

  0
end

def fib(number)
  return number if number <= 1

  fib(number - 1) + fib(number - 2)
end

base = memory_kb

start_time = Time.now
result = fib(30)
duration_ms = ((Time.now - start_time) * 1000).to_i

peak = memory_kb

puts "Result: #{result}"
puts "Execution Time: #{duration_ms}ms"
puts "RAM: #{peak} KB"
puts "Used in Run: #{peak - base} KB"
```

To keep the comparison reproducible, I ran both interpreters from the same container. The Dockerfile builds PicoRuby from source in one stage, then copies the resulting binary into a slim runtime image alongside the benchmark script.

```dockerfile
FROM ruby:3.4-slim AS builder

RUN apt-get update && apt-get install -y \
    build-essential \
    git \
    libssl-dev \
    cmake \
    && rm -rf /var/lib/apt/lists/*

RUN gem install rake

RUN git clone --recurse-submodules https://github.com/picoruby/picoruby /picoruby

WORKDIR /picoruby
RUN bundle install && rake

FROM ruby:3.4-slim

RUN apt-get update && apt-get install -y \
    build-essential \
    && rm -rf /var/lib/apt/lists/*

COPY --from=builder /picoruby/bin/picoruby /usr/local/bin/picoruby
COPY benchmark.rb /app/benchmark.rb

CMD ["/bin/sh", "-c", "echo 'CRuby' && ruby /app/benchmark.rb && echo '' && echo 'PicoRuby' && picoruby /app/benchmark.rb"]
```

The results make the trade-off clear.

```text
$ CRuby
Result: 832040
Execution Time: 52ms
RAM: 13204 KB
Used in Run: 0 KB

$ PicoRuby
Result: 832040
Execution Time: 222ms
RAM: 5044 KB
Used in Run: 64 KB
```

- CRuby finished in 52ms and used 13,204KB of RAM.
- PicoRuby finished in 222ms and used 5,044KB of RAM.
- During the benchmark run itself, PicoRuby reported an additional 64KB of memory usage.

So while PicoRuby is slower in this benchmark, it cuts the resident memory footprint by roughly 62% compared to standard CRuby. That is the difference that makes Ruby plausible on much smaller devices.

If the goal is developer ergonomics on servers, CRuby is still the obvious choice. But if the goal is embedding Ruby into tiny hardware environments, PicoRuby is a compelling reminder that the Ruby family is much broader than web development alone.

Useful links:

- [PicoRuby on GitHub](https://github.com/picoruby/picoruby)
- [PicoRuby documentation](https://picoruby.github.io/)

You Can Run Ruby in Less Than 150KB of RAM


Linux exposes Bluetooth devices through BlueZ, its official Bluetooth stack, over D-Bus. That means any language with a D-Bus binding can talk to your Bluetooth devices directly, no special framework needed. Ruby has `ruby-dbus`, and that is all you need.

The setup requires two system packages and one gem.

```bash
# Install BlueZ (Linux Bluetooth stack)
sudo apt install -y bluez bluez-tools

# Install Ruby gem for D-Bus
gem install ruby-dbus
```

Before writing any Ruby, you need to pair the device and find its GATT characteristic paths. BlueZ ships with `bluetoothctl`, an interactive shell that handles all of this.

```bash
# Open bluetoothctl
bluetoothctl

# Inside bluetoothctl
power on
scan le
# wait for device to appear:
# [NEW] Device E7:9D:09:EF:F5:8F JBL Tune 520BT-LE
scan off

# Connect and wait for services to resolve
connect E7:9D:09:EF:F5:8F
# wait for:
# [CHG] Device E7:9D:09:EF:F5:8F ServicesResolved: yes

# Discover GATT paths
menu gatt
list-attributes E7:9D:09:EF:F5:8F
# look for:
# Battery Level  -> .../service0033/char0034
# Manufacturer   -> .../service0037/char0038
# Model Number   -> .../service0037/char003a
```

Once services resolve, `list-attributes` dumps every GATT characteristic the device exposes. The paths you care about are the ones mapped to Battery Level, Manufacturer Name, and Model Number. Those paths go directly into the Ruby script.

The script connects to the system D-Bus, reads the static device info once by polling, then subscribes to the `PropertiesChanged` signal on the battery characteristic so it receives updates without polling at all.

```ruby
require 'dbus'

BLUEZ_SERVICE        = "org.bluez"
DEVICE_PATH          = "/org/bluez/hci0/dev_E7_9D_09_EF_F5_8F"
BATTERY_CHAR_PATH    = "#{DEVICE_PATH}/service0033/char0034"
MANUFACTURER_PATH    = "#{DEVICE_PATH}/service0037/char0038"
MODEL_PATH           = "#{DEVICE_PATH}/service0037/char003a"

GATT_INTERFACE       = "org.bluez.GattCharacteristic1"
PROPERTIES_INTERFACE = "org.freedesktop.DBus.Properties"

def read_characteristic(bluez, path)
  obj = bluez.object(path)
  obj.introspect
  obj[GATT_INTERFACE].ReadValue({}).first
end

def bytes_to_string(bytes)
  bytes.map(&:chr).join.strip
end

# Connect to system D-Bus
bus   = DBus::SystemBus.instance
bluez = bus.service(BLUEZ_SERVICE)

# Read static device info (polling - these never change)
manufacturer = bytes_to_string(read_characteristic(bluez, MANUFACTURER_PATH))
model        = bytes_to_string(read_characteristic(bluez, MODEL_PATH))

puts "Device : #{manufacturer} #{model}"

# Setup battery characteristic for notifications
battery_obj = bluez.object(BATTERY_CHAR_PATH)
battery_obj.introspect

battery_gatt  = battery_obj[GATT_INTERFACE]
battery_props = battery_obj[PROPERTIES_INTERFACE]

# Subscribe to PropertiesChanged signal
# BlueZ emits this signal whenever the characteristic value changes
battery_props.on_signal("PropertiesChanged") do |iface, changed, _|
  next unless iface == GATT_INTERFACE
  next unless changed["Value"]

  battery = changed["Value"].first
  puts "[#{Time.now.strftime('%H:%M:%S')}] Battery: #{battery}%"
end

# Tell the device to start sending notifications
battery_gatt.StartNotify

puts "Listening for battery notifications... (Ctrl+C to stop)"
puts

# D-Bus event loop - blocks here and fires the signal handler above
main_loop = DBus::Main.new
main_loop << bus
main_loop.run
```

A few things worth noting. `ReadValue` returns an array of bytes, so `bytes_to_string` maps each byte to its ASCII character and joins them. The `on_signal` block receives every `PropertiesChanged` event on that object, so the two `next unless` guards filter out unrelated interfaces and signals that carry no `Value` key. `StartNotify` tells the device to begin pushing updates, and the D-Bus main loop sits at the bottom blocking the process and dispatching incoming signals to the registered handlers.

The result is a script that prints a timestamped battery percentage every time the headphones report a change, with no polling loop and no external process to manage.

The same pattern applies to any GATT characteristic your device exposes. Swap the path, adjust the byte parsing, and you have a live stream of whatever data the device is broadcasting.


Ruby, Linux and Bluetooth


Modern cars communicate internally over CAN bus, a protocol where every module on the vehicle broadcasts short frames that any other module can read. Linux exposes this bus through SocketCAN, a kernel framework that abstracts a CAN adapter as a standard network interface. Once the interface is up, any application that can open a socket can read from it, including Ruby with no external gems.

The first step is getting the virtual interface running for local testing, plus the `can-utils` package that ships `cansend`.

```bash
# Loading vcan kernel module
sudo modprobe vcan

# Create a virtual CAN interface
sudo ip link add dev vcan0 type vcan

# Bring vcan0 up
sudo ip link set up vcan0

# Install CAN utilities
sudo apt-get install -y can-utils
```

For a real USB-CAN adapter you would instead bring up `can0` with the correct bitrate for the vehicle:

```bash
sudo ip link set can0 up type can bitrate 500000
```

With the interface up, you need something sending frames to read. This script simulates an ECU replying to OBD-II speed requests once per second with a random value between 0 and 180 km/h.

```ruby
# car_simulator.rb
INTERFACE = "vcan0"
ECU_ID    = "7E8"
MODE      = "41"    # OBD-II mode 01 response
PID_SPEED = "0D"    # Speed PID (SAE J1979)
PADDING   = "0000000000"

loop do
  speed = rand(0..180).to_s(16).rjust(2, '0')
  system("cansend #{INTERFACE} #{ECU_ID}#04#{MODE}#{PID_SPEED}#{speed}#{PADDING}")
  sleep 1
end
```

The `cansend` format is `INTERFACE ID#DATA`. The ECU response ID `7E8` is the standard OBD-II reply address. Mode `41` means "mode 01 response", PID `0D` is vehicle speed, and the speed byte is a single hex value where the raw byte equals km/h directly.

The monitor opens a raw CAN socket, binds it to the interface using a couple of low-level ioctl calls, then sits in a loop reading 16-byte frames and decoding only the speed ones.

```ruby
# monitor.rb
require 'socket'

PF_CAN        = 29
CAN_RAW       = 1
INTERFACE     = "vcan0"
SIOCGIFINDEX  = 0x8933
ECU_RESPONSE  = 0x7E8   # OBD-II ECU response ID
MODE_RESPONSE = 0x41    # mode 01 response
PID_SPEED     = 0x0D    # vehicle speed PID (SAE J1979)
FRAME_SIZE    = 16
IFREQ_PACK    = "a16i"
SOCKADDR_PACK = "S S i Q"
FRAME_UNPACK  = "V C x3 a8"

socket = Socket.new(PF_CAN, Socket::SOCK_RAW, CAN_RAW)

# Build an ifreq struct: interface name (16 bytes) + integer placeholder
# The kernel will fill the integer with the interface index
ifreq = [INTERFACE, 0].pack(IFREQ_PACK)

# Ask the kernel for the numeric index of the interface (e.g. vcan0 -> 3)
# SIOCGIFINDEX is a Linux ioctl that resolves interface name -> index
socket.ioctl(SIOCGIFINDEX, ifreq)

# Extract the interface index written by the kernel into bytes 16..19
if_index = ifreq[16, 4].unpack1("i")

# Build a sockaddr_can struct and bind the socket to the CAN interface
# The kernel requires: [family, index, padding] packed as binary
socket.bind([PF_CAN, if_index, 0, 0].pack(SOCKADDR_PACK))

loop do
  # Block until a CAN frame arrives - always 16 bytes (linux/can.h)
  raw_frame = socket.recv(FRAME_SIZE)

  # Unpack the binary frame:
  # V = 32-bit little-endian CAN ID
  # C = 1 byte data length
  # x3 = skip 3 padding bytes
  # a8 = 8 bytes of raw data payload
  can_id, _, data = raw_frame.unpack(FRAME_UNPACK)

  # Ignore frames that are not OBD-II ECU responses (ID 0x7E8)
  next unless can_id == ECU_RESPONSE

  # Byte 1 = mode response (0x41), byte 2 = PID - skip if not speed
  next unless data[1].ord == MODE_RESPONSE && data[2].ord == PID_SPEED

  # Byte 3 is the speed value - OBD-II formula: speed (km/h) = A directly
  speed = data[3].ord
  puts speed
end
```

A few details worth understanding. `PF_CAN` (29) is the protocol family for CAN sockets, the same way `PF_INET` is for TCP/IP. The frame format is fixed at 16 bytes by the kernel's `linux/can.h`: 4 bytes for the CAN ID, 1 byte for the data length, 3 padding bytes, and 8 bytes of payload. The `unpack` format string `"V C x3 a8"` maps exactly to that layout.

The two `next unless` guards do the filtering: the first rejects any frame not from the ECU reply address, and the second checks that the mode and PID bytes match so you only act on speed frames and ignore everything else on the bus.

Running the simulator in one terminal and the monitor in another gives you a live stream of speed values with no gems, no OBD library, and no abstraction layer between Ruby and the kernel socket.


Spinel: The Compiled Ruby

Prism for Massive-Scale Code Analysis

You Can Run Ruby in Less Than 150KB of RAM

Ruby, Linux and Bluetooth

Ruby + SocketCAN: Listening to Your Car's Hardware