Swift.CodeCompared.To/Ruby

Both languages let the file body be the program. Ruby goes further and drops the parentheses too — puts "x" is a method call with the parentheses omitted, which is legal on every call and is the house style. It takes about a week to stop feeling like something is missing.

There is no let: a capitalized name makes a "constant", and Ruby's idea of constant is a warning printed to stderr rather than an error. The immutability discipline is entirely on you. What Ruby does freeze, as of 4.0, is string literals — "hello" << " world" now raises FrozenError, which is the language quietly conceding the point. Note that the quote style matters: single-quoted strings do no interpolation and no escape processing at all.

The practical consequence is that a method call is the only thing that ever happens — 3 + 4 is 3.+(4), and if, while and case are the short list of things that are not. That uniformity is what makes 3.times, 5.downto(1) and 1.step(10, 2) possible, and it is why the answer to "can I add a method to that" is always yes.

The trade is exactly the one this page keeps finding: a symbol costs nothing to introduce and nothing checks that you spelled it right, so :activ is a perfectly good symbol that simply never matches. Two Ruby-specific facts worth knowing early: symbols are compared by identity so == on them is a pointer comparison, and 🚨 symbols created from user input are never garbage collected — String#to_sym on untrusted data is a memory leak, and to_sym on a fixed set of names is fine.

Everything the Swift compiler does for you is gone: no type checking, no exhaustiveness, no null safety, no arity checking of a block you passed along. A typo is a NoMethodError at the moment that line executes, which is why Ruby culture is so test-obsessed — the test suite is the type checker, and it is not optional. What you get back is duck typing: describe above accepts anything with a name and an age, with no protocol declared and no conformance to write, which is why mocking and adapting in Ruby take no ceremony at all.

What Swift gets from the declaration is a compiler that can list every conforming type, refuse a non-conforming one at the call site, and rename the method across all of them. What Ruby gets is that a type written years later by someone else satisfies your function without either side knowing — and that a test double needs only the one method you actually call, which is why Ruby testing needs no mocking framework to substitute a collaborator. respond_to?(:describe) is the run-time check when you need one.

Generics exist in Swift to let the compiler check a function it will stamp out per type. With no compile-time checking there is nothing to parameterize, so the whole feature is unnecessary rather than missing. What you lose with it: the constraint is no longer written down anywhere, so "what does this method require of its argument" is answered by reading the body. The Ruby convention that partly replaces it is to document the duck type and to raise early — raise ArgumentError unless value.respond_to?(:<=>).

Ruby has &. (safe navigation) and || (nil-coalescing), so the operators feel familiar — but nothing makes you use them, and undefined method 'upcase' for nil is the error you will meet most often. Two Ruby-specific notes. nil is a real object with methods (nil.to_a is [], nil.to_s is ""), which makes a surprising amount of code survive it. And only nil and false are falsy — 0 and "" are truthy — so value || default is not quite ??: it also fires when the value is legitimately false.

🚨 The difference that bites: || is not ??. It falls back on false as well as nil, so enabled || true is wrong for a boolean that is legitimately false. Ruby's exact equivalent is the safe-assignment form value = other if value.nil?, or value.nil? ? fallback : value. And because only nil and false are falsy in Ruby — 0 and "" are truthy — || is safer here than the same operator is in JavaScript or Python.

NoMethodError: undefined method '+' for nil is the single most common Ruby error in production, and it is what Swift's optionals exist to make impossible. The defenses are ordinary and worth adopting: fetch rather than [] on a hash so a missing key raises immediately, Array#dig and Hash#dig for nested access, guard clauses at the top of a method, and &. where nil is genuinely expected. Ruby 3's NoMethodError also now suggests the method you probably meant.

A block is passed to every method invisibly, and yield calls it — so a method that takes a block declares nothing, and control structures that look built-in (3.times, each, File.open) are just methods with blocks. That is why Ruby needs no defer: File.open(path) { |file| … } closes the file when the block ends, which is Swift's defer and with expressed as an ordinary method. The idioms to pick up are |parameters| (Swift's $0 is |number|, named), &:symbol (map(&:to_s)), and ->() { } for the rare case where you need a closure as a value.

The mapping is almost a rename — filter is select, first(where:) is find, contains is any?, mapValues is transform_values — and then Enumerable keeps going, with tally, partition, each_cons, each_slice, chunk_while, each_with_object and dozens more. This is the part of Ruby that will actually make you happy: it is the richest collection library of any language on this site, and any class becomes a full member of it by defining each and include Enumerable. .lazy even means the same thing it does in Swift.

That invisibility is the single biggest structural difference from Swift closures, and it is what makes Ruby read the way it does: each, times, File.open and every Rails DSL are one method plus one block. Two things worth knowing: block_given? tests whether a block was passed, and prefixing a parameter with & (def each(&block)) captures it as a real object you can store or pass on — which is the point where it becomes a Swift closure again.

That is the better arrangement of the two for anything a library hands out, and it is why File.open(path) { |file| … } is the idiomatic form rather than open plus close. ensure runs on every path out including an exception, exactly as defer does. Where Swift's version wins is a local resource in the middle of a long method — Ruby has no equivalent short of restructuring, and the usual answer is that the method was too long anyway.

Without lazy, select on an infinite range never returns — the same trap as leaving .lazy off a Swift sequence. Ruby's Enumerator::Lazy supports map, select, reject, take_while and first, and Enumerator.new lets you write a producer of your own. A generator-shaped method is Enumerator plus yielder << value, which is close to Swift's AsyncStream in feel and entirely synchronous.

The "uniform access principle" is doing quiet work here: a Ruby getter is a method, so rectangle.area and rectangle.width look identical to a caller and either can be swapped for the other without changing a single call site — which is what Swift's computed properties buy you, arrived at from the other direction. attr_reader/attr_accessor generate the accessors (and they are themselves ordinary method calls that write methods — see Metaprogramming). Instance variables (@width) are always private; there is no way to reach one from outside except through a method.

A Swift extension can add to a type but never change it: uppercased() means what it always meant, no matter what any library does. Ruby has no such protection — reopening Integer and redefining even? is legal, global, and instantly affects every gem in the process. This is "monkey patching", it is genuinely powerful (Rails is built on it), and it is how a language gets a reputation for spooky action at a distance. refine is the scoped, sanctioned version, and almost nobody uses it. Treat the ability the way you treat unsafeBitCast.

Two conveniences transfer directly: keyword arguments with defaults line up with Swift's argument labels, and a method returns its last expression so return is usually omitted. The difference underneath is that an instance variable is created on first assignment, so a typo in @vlaue makes a second variable rather than an error — and reading an unset one returns nil rather than failing. That is the same trade as everywhere else on this page, in the place it costs most.

There are no value types in Ruby at all — every object is a reference, and the copy-on-assignment reasoning a Swift developer relies on does not hold anywhere. Data.define, added in Ruby 3.2, is the closest thing and is the one to reach for: it is frozen, compares by value, and has a with method that returns a modified copy, which together give you most of what a Swift struct guarantees. Reaching for it wherever you would have written a struct is the single habit most worth carrying across.

A module is a protocol and a protocol extension in one: include Comparable mixes its methods into your class, and — exactly as in Swift — you implement one primitive (<=>, the "spaceship" operator) and inherit every comparison operator, sort, max, min and clamp for free. include Enumerable works the same way from each. The difference is that modules are dynamic: nothing declares conformance at compile time, nothing checks that you implemented <=>, and a missing method surfaces as a NoMethodError the first time someone sorts your objects.

The same pattern is the whole of Enumerable: define each, include the module, and you have map, select, reduce, sort_by, group_by, min, max and about forty more. That is considerably more leverage than a Swift protocol extension, because the protocol requirement is a single method rather than a set — and it costs the thing this page keeps naming: nothing checks that your class defines <=> until something calls it.

So module does two unrelated jobs: mixed into a class it adds instance methods, and used on its own it groups names. The :: separator reaches a constant, and constants are any name starting with a capital — which means a class name is a constant, and reassigning one is a warning rather than an error. Ruby has no private at file scope, so a module is also how you keep a helper out of the global namespace.

Ruby 3's case/in is a real structural pattern match: it deconstructs objects (any class can opt in with deconstruct/deconstruct_keys), and it matches the shape of hashes and arrays, which switch cannot do. What it does not have is exhaustiveness — nothing tells you a case is missing, and an unmatched value raises NoMatchingPatternError at run time. That is louder than Python's silent fall-through, and it is still not the compile-time guarantee that makes Swift enums safe to extend. (Note also the older case/when, which is a different construct: it tests with === and does no destructuring.)

That makes when extensible in a way a Swift switch is not: define === on your own class and it can appear in a when. 🚨 Notice the two columns disagree about 3.5: Swift falls through to the default, while Ruby answers in range because (1..10) === 3.5 is true — a Range covers a float, which is === doing exactly what it is documented to do and not what a reader skimming the branches expects. What is missing is exhaustiveness — a case with no else that matches nothing returns nil rather than failing to compile, which is the single most consequential difference from switch. Use case/in, in the row above, when you want structure rather than class membership.

Read the left column again: Swift gives you read-only reflection and compile-time macros, and that is deliberate — the compiler must be able to know every method that exists. Ruby gives you define_method (write a method at run time), method_missing (intercept a call to a method that does not exist), public_send (call a method by name), and instance_variable_get. That is not a dark corner of the language; it is how attr_accessor itself works, and it is why an ActiveRecord model gets a method per database column without anyone writing one. The price is exactly what you would guess: your editor cannot autocomplete it, your reader cannot grep for it, and the compiler that would have caught the typo does not exist.

This is the mechanism behind most of Ruby's famous libraries, and it is also how a typo becomes a plausible-looking answer instead of an error. Two obligations that go with it: always define respond_to_missing? alongside it, or respond_to? lies and method(:name) fails; and prefer define_method when the set of names is known in advance, because a real method is faster, appears in methods, and can be found by anyone reading the code. Swift's @dynamicMemberLookup is the deliberately narrow version of the same idea.

This is where a Swift developer should be most careful, because it is genuinely powerful and genuinely hard to read: the methods do not appear in the source, so grepping for active? finds nothing. Ruby's own answer is that the loop should be short and obvious, and that send — which calls any method by a computed name, including a private one — should never be handed a name from user input. Macros are Swift's equivalent and run at compile time, which is the whole difference.

The throws annotation is gone, so nothing in a signature warns a caller that a method can raise — the information Swift puts in the type system lives in the documentation. rescue is catch, ensure is finally (and doubles as Ruby's defer), and a method body is implicitly a begin block, so rescue can appear at method level with no wrapper. Two conventions worth knowing: rescue StandardError, never bare Exception (which would swallow SignalException and NoMemoryError); and many standard-library methods offer a nil-returning alternative (Integer(text, exception: false)) so that expected failure needs no exception at all.

retry is genuinely useful and genuinely easy to misuse: with no counter it is an infinite loop, so the guard is not optional. ensure is defer scoped to the block rather than the function. Two more differences worth knowing: rescue with no class catches StandardError rather than everything, which is what you want — catching Exception also catches Interrupt and SystemExit — and a custom error should subclass StandardError for the same reason.

Swift 6 added typed throws, which moves in exactly the opposite direction — so this is one of the widest gaps on the page. What Ruby offers instead is convention: raise a subclass of StandardError so rescue catches it, define one error class per library so callers can rescue a namespace, and use the bang suffix where it exists (Integer(text) raises, text.to_i returns 0). That last pair is worth internalizing early — "oops".to_i is 0, silently, which is exactly the kind of thing Swift's optionals exist to prevent.