April 27, 2026

Scan to try

🎯 Live Demo Available

Introducing

MapView

Render beautiful, production-ready maps directly from your Ruby on Rails backend. No external APIs. No dependencies. Just pure speed and control.

✓

Zero external dependencies

✓

Lightning-fast rendering

✓

Production-ready & battle-tested

Try the Live Demo → Read Docs

This post connects a Japanese presentation experimenting with Spinel, introduced at RubyKaigi 2026, with real execution tests.

The goal is simple: what actually works today?

The idea

Spinel compiles:

Ruby → C → native binary

This removes the Ruby runtime, but also limits what Ruby features can be supported.

Testing under pressure

I used problems from AtCoder, where:

• input/output must be exact
• execution must be deterministic
• crashes are immediate failures

What breaks first

A, B, C = gets.chomp.split(' ').map(&:to_i)

• ❌ compilation error (constants)

a, b, c = gets.chomp.split(' ').map(&:to_i)

• ❌ compiles
• ❌ runtime crash (segfault)

Cause: chained input parsing

What works

arr = gets.split(' ')
a = arr[0].to_i
b = arr[1].to_i
c = arr[2].to_i
cap = a - b
trans = [cap, c].min
puts c - trans

• ✅ compiles
• ✅ runs correctly

Key insight

Spinel currently supports:

Ruby written in a very explicit, step-by-step style

Idiomatic Ruby tends to break.

Can you use it in contests?

On platforms like AtCoder:

• possible via binary embedding (base64)
• not reliable
• not aligned with the submission model

👉 not viable for serious use

Why it matters

Spinel is not about competitive programming.

It is exploring a different question:

what Ruby looks like as a compiled language

That direction could enable:

• standalone binaries
• faster startup
• new deployment models

Final take

Spinel works today, but only within a narrow subset of Ruby.

Understanding that boundary is the interesting part.

Source