What gets preserved and what gets lost when you compile a language that was designed, from its first line of syntax, to be dynamic.
Open a Crystal file next to a Ruby file and for the first ten lines you might not be able to tell them apart. Same blocks, same string interpolation, same feel. Then you try to eval a string, or monkey-patch a class based on which plugin got loaded at runtime, and the resemblance ends abruptly. Crystal did not set out to clone Ruby’s runtime. It set out to keep Ruby’s syntax while compiling to native code through LLVM, and that single decision quietly determines everything the language can and cannot do.
A Language Built to Answer One Complaint
Crystal began in 2011 inside Manas Technology Solutions, an Argentine software shop whose developers, Ary Borenszweig, Juan Wajnerman, and Brian Cardiff, liked writing Ruby and disliked how often they had to rewrite it in something else once performance mattered. Their stated reasoning was direct: Ruby’s dynamic nature made it fundamentally impossible to get C-like speed out of it, so rather than fight that nature they built a new language that looked like Ruby but was not one. The project, first called Joy, became self-hosting in November 2013, shipped its first public release in June 2014, and reached a stable 1.0 in March 2021.
What Makes This Possible: Whole-Program Type Inference
The mechanism underneath Crystal’s “write Ruby, get native speed” pitch is whole-program type inference. Rather than inferring a variable’s type from its immediate context the way most statically typed languages do, Crystal’s compiler analyzes the entire program at once, following every call site to work out what types flow through it. That is why Crystal code rarely needs type annotations even though it is fully statically checked, and it is also why Crystal cannot support several things Ruby takes for granted. If the compiler must see the whole program to infer types correctly, then nothing can be added to that program after compilation without invalidating the inference it already did. Runtime eval, runtime require, and dynamically loaded plugins that add methods to existing classes all violate that closed-world assumption, so none of them exist in Crystal.
What Survives the Trip From Ruby
A surprising amount does. Blocks, do/end syntax, string interpolation, symbol-like literals, module mixins through include and extend, operator overloading, and the general shape of the standard library all carry over closely enough that idiomatic Ruby code is often recognizable, sometimes even valid, as Crystal. Reopening a class to add methods to it is still legal syntax too, which surprises people who assume static typing rules it out automatically.
| Ruby | Crystal | Note |
|---|---|---|
respond_to? | responds_to? | Renamed, same purpose |
Enumerable#detect | Enumerable#find | Ruby’s alias is dropped |
and / or | && / || | Word operators removed entirely |
| Reopening a class at any time | Reopening a class | Still legal, but must be visible to the compiler at build time |
true/false as objects of TrueClass/FalseClass | Bool type | Simplified, no class hierarchy for booleans |
What Gets Left Behind
The losses cluster around exactly the features that require the program to change shape after the compiler has already reasoned about it. Ruby’s eval has no Crystal equivalent at all. Ruby’s method_missing, which lets an object intercept any undefined method call at runtime and decide what to do with it, exists in Crystal only as a compile-time macro hook: it operates on the call’s syntax tree during compilation and generates real, statically typed code from it, rather than intercepting arbitrary calls while the program is running. According to Crystal’s own documentation, the hook only applies to calls the compiler can already see within the same class or its descendants, which is a fundamentally different guarantee than Ruby’s fully open runtime dispatch.
Monkey patching survives syntactically but not in spirit. You can still reopen String or Array and add a method, but that patch has to exist in the source the compiler sees before it builds the binary. Loading a gem at runtime that patches a core class based on a configuration flag, a common Ruby-on-Rails pattern, simply is not expressible, because by the time the program is running, the type inference that made the whole thing fast has already happened and cannot be redone.
Even something as basic as integer arithmetic changes character. Ruby’s integers are arbitrary precision by default and silently promote to a Bignum when they overflow. Crystal’s integers are fixed-width types like Int32 and Int64, chosen for predictable memory layout and speed, and an operation that overflows one raises an OverflowError instead of quietly growing. That is a deliberate trade of Ruby’s forgiving arithmetic for the kind of behavior a systems language needs.
| Ruby feature | Crystal reality |
|---|---|
eval arbitrary code at runtime | Not supported in any form |
method_missing intercepts any call at runtime | Compile-time macro hook operating on known call sites only |
Runtime require based on a variable | All requires resolved at compile time |
| Monkey-patching via a dynamically loaded plugin | Patches must be visible in source before compilation |
| Integer auto-promotion to Bignum on overflow | Fixed-width integers raise OverflowError |
The Payoff: Real Performance Numbers
None of this is a trade worth making unless the performance side actually delivers, so it is worth looking at measured numbers rather than marketing claims. The independently maintained Crystal Benchmarks Game project runs the same Computer Language Benchmarks Game tasks in Crystal, C, and Ruby on identical hardware.
The gap is real but not uniform. On mandelbrot and spectralnorm, both numerically heavy and dominated by tight arithmetic loops, Crystal finishes 44 to 148 times faster than Ruby. On regexdna, where both languages are mostly waiting on the same underlying C regular expression engine, Crystal and Ruby finish within a few percent of each other, since neither language’s own execution speed is the bottleneck there. That pattern is the honest version of the pitch: Crystal wins big exactly where Ruby’s interpreter overhead was the problem, and wins by very little where it wasn’t.
Where the trade tends to make sense:
- CPU-bound services where Ruby’s interpreter overhead is the actual bottleneck
- Teams that want Ruby’s readability without reaching for a second language at the performance-critical layer
- Long-running services where compile-time checking catches errors before they reach production
Where it tends not to:
- Codebases that lean heavily on runtime metaprogramming, dynamic plugin loading, or
eval-based DSLs - Rapid prototyping workflows that depend on redefining behavior without recompiling
- Projects that need Ruby’s exact gem ecosystem rather than Crystal’s smaller one
What We Have Learned
Crystal’s resemblance to Ruby is not a coat of paint over an unrelated compiler, and it is not a faithful reimplementation either. It is the specific and fairly narrow set of Ruby features that remain expressible once you commit to inferring types across an entire, unchanging program at compile time. Blocks, mixins, and most of the standard library survive that constraint easily. Runtime metaprogramming, dynamic loading, and arbitrary-precision arithmetic do not, because each of them assumes the program can still change after the compiler has finished reasoning about it. The real benchmark numbers show the trade paying off precisely where Ruby’s dynamism was costing the most, which suggests the designers understood exactly which parts of Ruby they were giving up and why.
