Ruby.CodeCompared.To/Odin

Ruby runs a file containing a single expression. Odin will not: there is no top-level code, no interpreter, and nothing happens until you have named a package, imported core:fmt, and declared a main. That ceremony is the smallest possible preview of the trade this whole page describes.

Losing irb is a real loss, and no amount of compiler speed fully replaces poking at a live object. What you get back is that Odin builds a whole project in a fraction of a second, so the edit-run loop stays close to Ruby's even without an interpreter.

This is the largest genuine loss on the page, and it should inform whether Odin suits your problem at all. For the game and graphics work Odin targets — short dependency lists, mostly C libraries already vendored — it costs less than it sounds. If your instinct on any new problem is to search rubygems.org first, no language feature compensates for that instinct being unavailable.

The declaration is the one place Odin asks for more typing than Ruby, and the reason is that a declaration is a distinct act here. Assigning to a name that was never declared is a compile error, so the typo that silently creates a new local in Ruby cannot happen.

Ruby's CONSTANT is a naming convention the interpreter grumbles about but permits, and the object it names stays mutable unless you freeze it. Odin's constant is enforced by the compiler and has no runtime existence at all.

The Ruby habit this breaks is not really rebinding a variable to a new type — it is the pervasive assumption that a method will accept anything that responds to the right messages. Every argument you pass in Odin has been checked before the program starts.

Ruby's promotion from Integer to bignum is so quiet that most Rubyists never think about the width of a number. In Odin the width is part of the type you chose, and choosing u8 for a counter that reaches 300 is a bug the compiler cannot see.

Ruby's rule that only nil and false are falsey is already stricter than most dynamic languages, and Rubyists lean on it constantly — if user, value || default, array.first&.name. All of that has to become an explicit comparison.

The defensive &. and || return scattered through mature Ruby code exists because any reference might be nil. In Odin a struct field is never absent — it holds its type's zero value. Pointers can still be nil, and the section on optionals covers the case where "no value" is genuinely meaningful.

Notice the defer delete on the results. strings.to_upper has to build a new string somewhere, so it allocates — and in a language with no garbage collector, whoever asked for the allocation owns it. Procedures that only read, like strings.contains, allocate nothing.

The %v verb is the closest thing Odin has to Ruby's to_s, and it works on every type — including your own structs, enums, and unions — with no code from you. Where Ruby calls a method the object defines, Odin walks the type information the compiler already emitted.

Repeated + concatenation allocates a fresh string every time in both languages — Ruby just hides the cost behind a garbage collector that cleans up after you. The builder makes the cost visible, and the defer on the next line makes the cleanup yours.

Ruby's String#length counts characters and bytesize counts bytes, so the character count is the one you get by default. Odin's len is bytes, because that is the number the machine actually stores — and the offsets the loop reports jump from 1 to 3 across the two-byte é.

This is one of the clearest wins on the page. A symbol typo in Ruby produces a case that silently matches nothing; the same typo in Odin does not compile. The switch is also checked for exhaustiveness, so adding a fourth status makes the compiler point at every place that needs updating.

Ruby offers both shapes — "x".to_i guesses and returns 0, Integer("x") raises. Odin only offers the reporting shape, so the 0 that a bad parse produces always arrives alongside the false that explains it.

The other half of the split is that every element must be the same type. Ruby's [1, "two", :three, nil] has no direct equivalent — you would reach for a slice of a tagged union, which the unions section covers, and the compiler would then make you handle every variant.

Ruby's Array#index returns the position or nil, and the caller distinguishes them. Odin's slice.linear_search returns the position and a bool, which is the same information without the sentinel — a shape you will see everywhere once you start reading Odin code.

Ruby returns nil for a missing key and lets you configure a different default with Hash.new(0). Odin always returns the value type's zero, so a map of counters already behaves like Hash.new(0) — and when zero is a legitimate stored value, the second return value is the only honest way to tell the two apart.

Ruby's Set is a Hash in a trench coat, and it works for anything hashable. Odin splits the job by what you actually have: a closed set of named states becomes a bit_set that costs one word and no allocation, and everything else becomes a map.

The real difference is that an Odin range is syntax, valid in a for header and a switch arm and nowhere else. Ruby's Range is an object you can store in a variable, pass to a method, or use as a hash key — none of which has an Odin equivalent.

Ruby's each is a method that takes a block, which is why 3.times, Integer#upto, and a custom each on your own class all look alike. Odin's for is a keyword the compiler understands, so it works on the types the language knows about and cannot be extended to yours.

This is the biggest day-to-day adjustment on the page — larger than losing the garbage collector, because you touch it in every procedure you write rather than once per subsystem. The honest consolation is the last example: a three-stage Ruby chain that allocates two intermediate arrays becomes one loop over the data with no allocation at all.

Making the captured state an explicit struct is more typing, and it is also exactly what Ruby builds behind the scenes when it heap-allocates a binding for the closure. The Odin version has no hidden allocation and no lifetime question about how long that binding survives.

This covers a good share of what blocks are used for: a comparator, a callback, a strategy chosen at runtime. What it cannot cover is the case where the behavior needs to remember something, and that is precisely the case Ruby uses blocks for most often.

A comparator is the ideal case for procedure values, because it genuinely needs nothing from the surrounding scope. The moment you want sort_by { |item| item.distance_to(origin) }, where origin is a local, the pattern breaks and you write the loop yourself.

Losing the trailing if modifier costs a line each time, and losing unless costs a !. The if statement; condition form pays some of it back: the variable exists only inside the branch, which is the scoping Ruby cannot give you.

Ruby's case/when is powered by ===, which any class can define — that is how it matches regexes, classes, ranges, and lambdas through one syntax. Odin's switch compares values and ranges of a single known type; the open-ended matching moves to the switch in over a tagged union in the unions section.

Ruby also has redo, retry in a rescue, and loop-like enumerator methods such as each_slice and each_cons. Odin has break, continue, and labeled versions of both for breaking out of a nested loop — which is genuinely useful and has no clean Ruby equivalent.

The important difference from ensure is placement. ensure sits at the bottom of the block, far from the File.open it balances; defer sits on the very next line, so a reviewer sees the acquisition and the release together. This keyword is what makes manual memory management bearable, and it appears constantly from here on.

Odin has no method-versus-function distinction, because there are no objects for a method to belong to. Everything is a procedure at package scope, and the thing it operates on is its first parameter.

This lands very close to modern Ruby, and the differences are small: = rather than : at the call site, and a default value that must be a compile-time constant. Ruby's def find(id, at: Time.now), where the default is evaluated per call, has no direct equivalent.

Ruby's version costs an array allocation and gives both values the same static type, which is to say none. The _ for a discarded result is Odin insisting you say so out loud; there is no equivalent of quietly using only the first element of a returned pair.

Ruby's **options hash has no equivalent, and that is mostly for the better: a struct with named fields gives you the same call-site readability, plus a compiler that catches prot: when you meant port:.

Ruby draws no such line: name = name.strip quietly rebinds a local while list << "added" quietly mutates the caller's object, and the two look identical at the call site. Odin makes the second one visible as &items, which is worth the extra character.

That last block is the difference a Rubyist feels first. other = point in Ruby gives two names for one object, and mutating through either is visible through both. In Odin it gives two independent points, and sharing requires an explicit ^Point.

The naming convention type_verb — rectangle_area, strings.to_upper, thread.create — does the work that a receiver does in Ruby. Ruby's bang convention for mutation becomes something the signature states outright: ^Rectangle mutates, Rectangle cannot.

Ruby's initialize can refuse to produce an object by raising. An Odin constructor has no such escape, so it returns the failure as a value — and a caller who ignores the ok gets a zeroed struct, which is at least a defined state rather than a half-built object.

Ruby gives you a default inspect too, and you override to_s when it is not good enough. Odin has no override — the formatting is derived from the layout, and a custom representation means writing your own procedure and calling it deliberately.

Nothing here dispatches. Ruby's describe calling an overridden speak is the whole point of inheritance, and Odin has no mechanism for it: a procedure taking a Dog takes a Dog. Runtime polymorphism has to be built explicitly, which the next section does.

This is the closed case, and it inverts Ruby's trade deliberately. Adding a shape in Ruby costs nothing and touches nothing; adding one in Odin makes the compiler point at every switch that now has a hole. Which you prefer depends on whether new variants or new operations arrive more often.

This is what a Ruby method call compiles down to anyway, minus the cache: find the code for this object, call it with the object. Writing it out is more work and drops all the safety, and the reason to prefer the tagged union above is precisely that it keeps the checking.

Odin does keep runtime type information, so this is not as far from Ruby as the rest of the page suggests — core:reflect can walk a struct's fields by name. What it cannot do is act on that information: there is no way to call something you discovered at runtime, because there is no method table to look in.

The cost is that every caller in the chain must handle or forward the error, where Ruby lets an exception fly past twenty frames to a rescue at the top. The benefit is that a procedure's signature tells you exactly what can go wrong, which a Ruby method's signature never does.

This gets error-value code close to the density of exceptions for the common case of "pass it up". What it deliberately will not do is skip frames: every procedure between the failure and the handler still declares the error in its signature, so the path is written down instead of inferred.

Ruby's block-taking with_resource guarantees the release, because the caller cannot forget to pass a block. Odin's defer is one line the author must remember to write, and forgetting it is the single most common source of leaks when moving to this language.

Ruby draws no line here: raise covers "the file was missing" and "this should be unreachable" alike, and rescue => error catches both, which is how a bug ends up silently swallowed in production. Odin's split is enforced — expected failures are return values, impossible states are panics.

It is worth being clear about what this costs and buys. You lose the freedom to allocate without thinking, and you gain the absence of collection pauses and the ability to say precisely when memory goes away. For a game frame or an audio callback that predictability is the entire point; for a script that runs once and exits, Ruby's bargain is obviously better.

A linked structure is where the absence of a collector is felt most sharply, because ownership stops being obvious: two nodes pointing at each other have no natural owner, and neither defer free knows about the other. The answer in practice is usually the arena two rows down — allocate the whole graph in one region and drop the region.

Reading Odin's standard library is largely a matter of asking "does this return something new, or a view into what I passed in?". strings.join builds a new string and must be deleted; strings.has_prefix only looks. The documentation says which, and getting it wrong leaks rather than crashes — which is why the tracking allocator below exists.

This is the feature that makes life without a collector practical, and it has no Ruby counterpart at all. Lifetimes that are genuinely bulk — everything a request touched, everything a frame drew — stop needing per-object ownership: allocate into the arena, reset it when the phase ends.

The temporary allocator is the closest Odin comes to Ruby's "just make a string and forget it", and the difference is where the sweep happens: you call free_all at a boundary you picked, instead of a collector choosing a moment you did not.

A leak means opposite things in the two languages. In Ruby it means something still holds a reference and the collector is right to keep the object; finding it means tracing who points at what. In Odin it means a delete was never written, and this tool names the exact line that allocated it — a considerably shorter investigation.

Ruby's require runs a file for its side effects and everything it defined lands in one global namespace, which is why gem authors nest everything under a module by convention. Odin's qualification is mandatory rather than conventional, so json.marshal and string_helpers.to_upper can never shadow each other.

What is missing is the dispatch, again. Comparable gives a Ruby class five methods in exchange for one <=>, and that trade depends on the module calling back into the class. Odin has no callback to make, so the shared code has to work on the shared data and nothing else.

Ruby's private is a runtime rule about receivers that send steps around, which is why so many gems reach into other gems' internals. Odin's is a compile-time fact with no escape hatch — private really is unreachable, for you and for everybody else.

The loss is smaller than it first appears. What you cannot do is make other people's code call your addition, which is precisely the power that makes monkey patching both wonderful and dangerous. Reading Odin, a call to shout is findable by grepping for shout ::, and there is exactly one.

This is the deepest difference on the page. Ruby's object model is a runtime data structure you can rewrite from inside the program, which is what makes ActiveRecord attributes and RSpec's DSL possible. Odin resolves every call at compile time, so a whole category of library design simply does not exist — and neither does the ten-frame stack trace through method_missing when it goes wrong.

Odin has no preprocessor, and when is why it does not need one — conditional compilation happens in the real language, with real scoping and real type checking on the branch that survives. Ruby's equivalent is an ordinary runtime if, so both branches must at least parse, and both ship.

Generics are the answer to a problem Ruby does not have — with no static types there is nothing to parameterize. What Odin gets in return is that largest(words) and largest(numbers) are two separately compiled procedures, each with no dispatch and no boxing, and a Stack(int) that cannot accidentally hold a string.

The line Odin draws is between inspecting and changing. You can ask what fields a struct has; you cannot add one, define a procedure, or call something discovered by name, because there is no method table to modify and no interpreter to compile new code into. Reflection here answers questions — it does not rewrite the program.

Ruby's nearest equivalents all leak: a module of integer constants accepts any integer, and symbols accept any symbol. The enum-indexed array is the piece with no Ruby analog at all — a lookup table the compiler proves is total.

Ruby's case on value.class does the same job with none of the guarantees — the list of possible types is in your head, and a new one arriving takes the else branch quietly. The union writes that list into the type, so a fourth variant makes every switch incomplete until you say what it does.

This inverts Ruby's default. There, everything is nullable and &. exists because you can never be sure; here, nothing is nullable unless its type says so, and the compiler makes you unwrap exactly the values that might be missing. It is the same discipline as Rust's Option or Swift's optionals, without the combinator vocabulary that needs closures.

Ruby's global VM lock means threads interleave rather than parallelize, so Thread.new is for waiting on I/O and Ractors or processes are for using more than one core. Odin gives you actual parallelism and, with it, actual data races: nothing warns you about the unlocked write, so the mutex is entirely your responsibility.

A loop that touches only x reads every cache line fully instead of skipping over y and alive, which is often several times faster on real data. Ruby cannot express this at any level: an array of objects is an array of pointers to separately allocated objects, and the layout belongs to the interpreter.

This is the one place on the page where Odin is the terser language. Ruby's Vector and Matrix are stdlib classes wrapping arrays, so every operation allocates a fresh object; Odin's live in registers and compile to vector instructions, which is what a language aimed at graphics work should do.