Perl.CodeCompared.To/Ruby

Ruby needs no use v5.38; preamble and no trailing semicolon — a newline ends a statement. puts is the direct equivalent of Perl's say: it prints a value followed by a newline. Ruby has no distinct "modern mode" to opt into; the behavior Perl gates behind use v5.38 is simply how Ruby always works.

Both languages are interpreted with no separate compile step, so ruby hello.rb and perl hello.pl feel identical to run. The difference shows up in exploration: Ruby ships irb, a full interactive REPL for trying expressions one at a time, where Perl programmers typically reach for a one-liner (perl -e) or the separate Devel::REPL module instead.

Both languages use # for single-line comments. Ruby additionally supports an =begin / =end block comment, borrowed directly from Perl's Pod (Plain Old Documentation) markers — but it is rarely used in practice; consecutive # lines are the idiomatic style in both languages for multi-line commentary.

Ruby's puts is exactly Perl's say — both append a trailing newline automatically. Ruby's print matches Perl's print with no added newline. Ruby additionally has p, which calls .inspect on its argument to show the type and structure of a value — invaluable for debugging and something Perl programmers usually reach for Data::Dumper to get.

Ruby has no sigils at all: a scalar, an array, and a hash are all referenced with a bare, unpunctuated name — the type is determined by what the variable holds, not by a leading $, @, or %. This eliminates an entire category of Perl syntax rules (element access uses $ even on an @array, interpolation context changes the sigil, and so on): in Ruby the name never changes no matter how the value is used.

Perl's my creates a genuinely new lexical variable scoped to the enclosing block, so an inner my $count shadows an outer one. Ruby has no declaration keyword for local variables — a bare assignment either creates or reassigns a variable in the current scope, and if/while blocks do not introduce a new scope the way a Perl { } block does. Only def, class, module, and blocks (do...end/{ } passed to a method) create new scopes in Ruby.

Both languages let a variable hold a value of any type at any time — neither requires a type declaration. The difference is uniformity: in Perl, a scalar variable can hold a number, a string, or a reference, but an @array variable can never hold a hash without going through a reference. In Ruby, one bare name can be reassigned freely between an integer, a string, or an array, because there is only one kind of variable.

Ruby constants are simply names that start with an uppercase letter — SCREAMING_SNAKE_CASE is the convention for simple values, exactly like Perl's use constant. Unlike Perl's pragma, Ruby needs no special declaration form: a plain assignment to an uppercase name is enough, and the runtime enforces the convention by emitting a warning (not an error) if the constant is later reassigned.

Ruby's truthiness is far simpler than Perl's: exactly two values are falsy, nil and false. Everything else is truthy — including 0, "", and critically the string "0", which is famously falsy in Perl. This "0 but true" trap that catches Perl programmers checking a string result does not exist in Ruby at all; a non-empty string is always truthy regardless of its content.

Both languages support list-style destructuring assignment and the classic temp-free swap idiom — Ruby inherited this pattern directly from Perl. Ruby's splat *tail plays the same role as Perl's @tail soaking up the remaining elements, but Ruby needs no explicit parentheses around the left-hand side and no sigils to distinguish which name captures the rest.

Perl interpolates a bare $name or @array directly inside a double-quoted string, but embedding an arbitrary expression like age + 1 requires the awkward @{[ expression ]} trick. Ruby's #{expression} syntax accepts any expression directly — method calls, arithmetic, ternaries — with no special-casing needed, because interpolation always evaluates Ruby code rather than only substituting a variable's value.

Perl's string operations are mostly standalone functions — length($text), uc($text), index($text, ...) — that take the string as an argument, and there is no built-in trim function at all (trimming needs a manual regex substitution). Ruby's String class has over 80 built-in methods called directly on the string object: text.strip, text.upcase, text.include?. The method-call style reads left-to-right and chains naturally.

Ruby's squiggly heredoc syntax (<<~LABEL) is essentially identical to Perl's — both strip the common leading indentation so the source code can be indented naturally without that indentation leaking into the string. Both interpolate variables and expressions by default; a single-quoted terminator (<<~'LABEL' in Ruby, <<~'LABEL' in Perl) disables interpolation in either language.

Ruby's % operator applies the same printf-style format specifiers Perl's sprintf and printf use — both languages inherited this format-string syntax from C. The single-argument form takes the value directly ("%05d" % 42); pass an array for multiple substitutions, exactly as Perl's sprintf takes a list of arguments after the format string.

Perl string scalars are always mutable — .= appends in place with no restriction. Ruby 4.0 freezes string literals by default, so an in-place mutation like << raises FrozenError unless the string was explicitly duplicated first with dup or the unary plus operator (+greeting). This is a deliberate safety feature with no Perl equivalent: it catches accidental mutation of a value another part of the program still expects to be constant.

Perl has one scalar type for all numbers — integers and floats are the same underlying representation, and very large integers silently become imprecise floating-point approximations once they exceed the native integer range. Ruby has a real Integer class with arbitrary precision: 2**64 is computed exactly, with no float promotion and no precision loss, no matter how large the number grows.

In Perl, checking parity or sign is an inline expression using % and comparison operators, and abs is a standalone function. Ruby integers are objects with predicate methods — even?, odd?, positive?, zero? — called directly on the number. 3.times { } replaces the for my $count (0..2) counting loop as a self-contained method call on the integer itself.

Perl's / always performs floating-point division regardless of operand types — getting an integer result requires int(...) to truncate. Ruby's / performs integer division automatically when both operands are integers, and floor division at that (rounds toward negative infinity, not toward zero). Both languages agree that % returns a result with the same sign as the right operand, so -7 % 3 is 2 in both.

Perl coerces strings to numbers implicitly in numeric context — "42" + 0 just works, with warnings if the string is not numeric-looking. Ruby requires explicit conversion methods: to_i, to_f, to_s. This is more typing but removes the ambiguity of Perl's automatic coercion, where a typo like "42abc" + 0 silently produces 42 with a warning rather than an error.

Ruby arrays are heap-allocated, dynamically sized, and can hold mixed types, just like Perl arrays. The mechanical difference is sigil consistency: Perl declares an array with @numbers but reads a single element with $numbers[0] (a common source of confusion for beginners), while Ruby uses the same bare name numbers everywhere regardless of whether you are addressing the whole array or one element.

Both languages support negative indexing from the end of the array and range-based slicing — Perl's array-slice syntax @numbers[1..3] maps directly onto Ruby's numbers[1..3]. Ruby additionally offers the start, length form (numbers[1, 3]) as an alternative to a range, and slicing an out-of-bounds range returns nil or an empty array rather than raising an error in either language.

Ruby's push, pop, shift, and unshift are named identically to Perl's built-in functions and behave the same way. The syntactic difference is that Perl's versions are standalone functions taking the array as a parameter (push @items, 4), while Ruby's are methods called on the array object itself (items.push(4)) — the same shift toward method-call syntax seen throughout string and array handling.

Perl's map and grep are Ruby's map and select almost one-to-one — both transform and filter a list with a block. Ruby adds reject as the inverse of select (Perl programmers negate the grep condition instead), and Ruby's block parameter is named explicitly (|number|) rather than relying on Perl's implicit $_ topic variable.

Perl needs the CPAN-distributed core module List::Util to get reduce, sum0, max, and similar aggregate functions — these are not built into arrays themselves and use the implicit $a/$b variables rather than named block parameters. Ruby's Enumerable module gives every collection reduce (alias inject) and sum for free, with a named accumulator parameter and no import required.

Perl's sort defaults to string comparison — sorting numbers correctly requires the explicit { $a <=> $b } comparator block, another common beginner trap. Ruby's sort uses the <=> spaceship operator automatically based on the element type, so numeric arrays sort correctly with no comparator needed. Ruby's flatten (recursively unwrapping nested arrays) and compact (removing nil) have no built-in Perl equivalent at all — Perl arrays cannot nest directly without going through references.

Just as with arrays, Perl declares a hash with the % sigil but reads an individual value with $scores{alice}, while Ruby uses one bare name (scores) for the whole structure and every access into it. Ruby's key: syntax (a symbol key) is the idiomatic default and reads closer to Perl's fat-comma key => value style than the older :key => value Ruby syntax it replaced.

Perl's exists checks for key presence without triggering autovivification, and // (defined-or) supplies a default when a value is undefined. Ruby has no exists keyword — bracket access on a missing key simply returns nil, and fetch is the strict counterpart: fetch(:key) raises KeyError on a missing key, while fetch(:key, default) mirrors Perl's // default pattern.

Perl's keys and values functions have direct Ruby method equivalents. Where Perl programmers loop with for my $key (keys %hash) and then look up $hash{$key} inside the loop, Ruby's each yields both the key and value together as block parameters in one step, and — like arrays — hashes include the full Enumerable module, so select, map, and sort_by all work directly on a hash.

Perl's autovivification lets $word_count{$_}++ spring a missing key into existence and treat undef as 0 for the increment — implicit and occasionally surprising. Ruby makes this explicit with Hash.new(0), which declares the default value for missing keys up front. Merging two hashes with later keys winning works the same way in both languages: Perl's (%defaults, %overrides) list-flattening versus Ruby's explicit merge method.

This is the single biggest conceptual difference between the two languages. In Perl, the same expression (@animals, or a parenthesized list) evaluates differently depending on whether it appears in a context that wants one value (scalar context) or many (list context) — assigning an array to a scalar silently gives you its length, but assigning a literal list (1, 2, 3) to a scalar gives you its last element, not its count. Ruby has no context sensitivity at all: an expression always evaluates to exactly one thing, and getting a count always means calling .length or .size explicitly. This eliminates an entire category of Perl surprises, but it also means Ruby cannot express Perl's occasionally-useful "give me count here, list there" idiom without writing it out explicitly.

Perl's wantarray lets a subroutine inspect the context it was called in and return a different value (or even a different shape of value) depending on whether the caller wants a list, a scalar, or nothing (void context). Ruby has no equivalent mechanism whatsoever — a method always returns the same value, and it is entirely up to the caller to decide what to do with it (call .first, .length, or use the whole thing). This is simpler to reason about but means the same expressive trick Perl uses for dual-purpose subroutines must be written as two differently named methods in Ruby.

Perl provides several ways to force scalar context on an array — the explicit scalar() function, or implicitly via numeric or string operators. Ruby has nothing to force, because there is no context to switch: an array is always an array object, and getting its length always means calling .length explicitly, whether inside a string interpolation or anywhere else. This makes Ruby code slightly more verbose in places but removes any ambiguity about what a given expression evaluates to.

Both languages spell the middle branch elsif (not else if). Ruby drops the parentheses around the condition and the curly braces around the body in favor of end — one character shorter than Perl's closing } but requiring the keyword to be spelled out. Ruby's if is also an expression that returns the matched branch's value, so it can be assigned directly: label = if temperature > 20 then "warm" else "cold" end.

Ruby borrowed unless and the postfix statement modifier directly from Perl, and the syntax is essentially identical between the two languages: statement if condition and statement unless condition both read as natural English guards. This is one of the strongest family resemblances between the two languages — a Perl programmer can write postfix conditionals in Ruby with no adjustment at all.

Perl's for/foreach over a range and Ruby's .each on a Range object accomplish exactly the same iteration, including support for character ranges like ("a".."e"). The structural difference is that Perl's for is a language keyword with special range syntax, while Ruby's range is a first-class object (1..5) that happens to support each along with the rest of the Enumerable module — map, select, sum, and more, all without a separate loop construct.

Both languages have while and until loops with the same semantics — until runs while the condition is false. Neither language has increment/decrement operators natively usable inside Ruby (++ and -- do not exist in Ruby at all — use += 1/-= 1), while Perl retains C-style ++/--. Ruby has no C-style do...while either; use loop do ... break if condition end for guaranteed first execution.

Perl once had an experimental given/when construct closely modeled on Ruby's case/when, but it was removed from modern Perl due to design problems with smart matching — the idiomatic replacement is a for ($topic) { if (...) { ...; last } } loop, which is considerably more verbose. Ruby's case/when remains a clean, permanent part of the language: each when clause uses === (case equality) for matching, supporting literal values, regexes, ranges, and comma-separated alternatives in one readable construct with no fallthrough to worry about.

Perl subroutines receive all arguments bundled into the single array @_ and must manually unpack them with my ($number) = @_; — there is no way to name parameters in the signature itself in the widely-used, portable syntax. Ruby methods declare named parameters directly (def square(number)), so there is no unpacking step. Both languages return the value of the last expression without a return keyword, though Perl programmers use return more consistently than Rubyists do.

Perl has no default-parameter syntax in the subroutine signature — the idiomatic approach is unpacking positionally from @_ and then using //= (defined-or assignment) to fill in a default for any argument left undef. Ruby supports default values directly in the method signature (greeting = "Hello"), evaluated at call time so dynamic defaults like def log(message, time = Time.now) work naturally with no manual assignment step.

Perl simulates keyword arguments by accepting a flat list of key-value pairs and unpacking it into a hash inside the subroutine (my (%args) = @_;) — there is no way for the signature itself to declare which keywords are required or provide defaults. Ruby has real keyword arguments as a language feature: name: and age: with no default are required and raise ArgumentError if omitted, while city: "Unknown" declares a default directly in the signature — no manual hash unpacking needed.

Since Perl subroutines already receive every argument in the flat list @_, "variadic" just means unpacking all of it into an array (or a hash, for key-value pairs) rather than a fixed number of named scalars. Ruby makes the intent explicit in the signature: *items collects remaining positional arguments into an array, and **attributes collects keyword arguments into a hash — both are visible in the method definition itself rather than inferred from how @_ happens to be unpacked.

Ruby 3.0 introduced an endless method syntax, def name(params) = expression, which reads like a mathematical definition. Perl has no equivalent single-line subroutine form in common use — even a trivial one-expression subroutine needs the full sub name { ... } block with an explicit argument-unpacking line, since there is no parameter list in the sub declaration itself.

This is one of Ruby's biggest wins over Perl. Perl has anonymous subroutines (sub { ... }) that must be explicitly created, stored in a scalar, and invoked with an arrow (->()) — there is no lightweight "just pass this code" syntax built into method calls the way iteration methods take a trailing block in Ruby. Ruby's do...end/{ } block is dedicated syntax for passing a chunk of code to a method with no explicit function-object ceremony: names.each do |name| ... end reads naturally and needs no ->() call syntax.

Perl callback-taking subroutines must accept the code reference as an explicit parameter and invoke it with the arrow call syntax ($callback->($count)). Ruby's yield lets any method accept an implicit block with no parameter declared in the signature at all — the block is simply attached at the call site with { ... } or do...end, and block_given? checks whether the caller supplied one. This is the mechanism behind every Ruby iterator: each, map, and select are all implemented with yield.

Perl code references (sub { ... } stored in a scalar) are directly analogous to Ruby's Proc objects — both store a block of code as a first-class value that can be passed around and called later with an arrow (->() in Perl, .call or .() in Ruby). Ruby additionally distinguishes lambda from proc: a lambda enforces its argument count strictly and treats return as returning only from the lambda itself, while a plain proc is more forgiving — a distinction Perl code references do not make.

Both languages support true lexical closures: an anonymous subroutine (Perl) or lambda (Ruby) captures the enclosing scope's variables by reference, and each call to the factory function creates a fresh, independent closure over its own copy of that state. This is one of the deepest similarities between the two languages — anywhere a Perl programmer reaches for a closure over my variables, the same pattern works in Ruby with -> or proc capturing local variables.

Perl requires an explicit backslash to create a reference and an explicit sigil ($$ref, @$ref, %$ref) to dereference it — references and values are visibly different things. Ruby has no separate reference concept at all: every variable already holds a reference to an object (except immediate values like small integers and symbols), so assigning one variable to another automatically shares the same underlying object, and mutating through either name is visible through both — no \ or $$ ceremony required.

Perl's [...] and {...} literals create anonymous references that must always be accessed through the arrow operator ($array_ref->[1], $hash_ref->{name}) or an explicit dereferencing sigil (@$array_ref). Ruby's [...] and {...} create real Array and Hash objects directly — the same literal syntax Perl uses for a reference is, in Ruby, simply the value itself, with no arrow and no dereferencing sigil ever needed.

An array of hashes, each holding a nested array, is common in both languages, but accessing it looks very different. Perl requires arrow-chaining through references ($person->{scores}) and an explicit @{ ... } dereference to get back to a plain array before iterating. Ruby's uniform object model needs none of this — person[:scores] already returns the array itself, so .sum and .size can be called directly with no dereferencing step at all.

Ruby inherited the =~ binding operator directly from Perl, along with the regex literal syntax and the numbered capture-group semantics — this is the strongest syntactic family resemblance between the two languages. The main practical difference is how the result is consumed: Perl assigns matched captures straight into the global variables $1, $2, while idiomatic Ruby prefers capturing the MatchData object returned by match and indexing into it (match[1]), though Ruby's $1/$2 globals exist too and work the same way after a successful =~.

Perl's s/pattern/replacement/ modifies a string in place by default and needs the /g flag to replace every occurrence rather than just the first — often paired with the (my $copy = $original) =~ s/... idiom to get a non-destructive copy. Ruby's sub and gsub are separate methods that always return a new string, leaving the original untouched (mirroring Perl's non-/g vs /g distinction as two distinctly named methods); the bang variants sub!/gsub! mutate in place if that behavior is wanted.

Named captures use the identical (?<name>...) syntax in both languages — Ruby adopted it directly from Perl, which introduced it in version 5.10. The only difference is how captured names are retrieved afterward: Perl exposes them through the %+ hash ($+{year}), while Ruby exposes them through the MatchData object returned by match (match[:year]), using a symbol key rather than a hash-style variable.

Both patterns for "find every match" exist in Perl and Ruby, but the mechanism differs. Perl relies on context sensitivity: the same =~ /pattern/g expression returns all matches when evaluated in list context, or advances an internal position pointer one match at a time when evaluated in scalar context inside a while loop. Ruby has one dedicated method for this, scan, which always returns every match (or yields each one to a block) with no context-dependent behavior to reason about.

Ruby uses the exact same modifier letters Perl does, in the exact same position after the closing delimiter: /i for case-insensitive, /m for multiline anchors, /x for extended mode allowing whitespace and comments inside the pattern. This is Perl's regex engine influence at its most direct — a Perl programmer's regex intuition transfers to Ruby almost without translation.

Perl OOP is built manually from two separate primitives: a package to hold the namespace, and bless to associate a plain hash reference with that package, making it recognizable as an object. Ruby bundles all of this into one class keyword — initialize replaces the hand-written new constructor, instance variables (@name) replace the manually managed blessed hash, and self inside a method replaces Perl's convention of my $self = shift; as the first line of every method.

Perl has no built-in accessor generation — every getter and setter is written out by hand, often using the combined pattern shown here ($self->{age} = shift if @_; detects whether the method was called as a setter). Ruby's attr_reader, attr_writer, and attr_accessor generate these methods with a single line each. Ruby setters also use a distinct, more readable call syntax: person.age = 31 instead of Perl's $person->age(31), because age= is a real method Ruby dispatches to when you use assignment syntax on an attribute.

Perl declares inheritance by populating the special array @ISA with a list of parent package names (or, in modern Perl, the more readable use parent 'Animal'; pragma) — method resolution walks @ISA depth-first to find an inherited method. Ruby uses the < operator directly in the class definition (class Dog < Animal), a single-inheritance declaration built into the syntax rather than assembled from a package variable. Both languages support calling the parent's version of an overridden method — Perl's SUPER::method, Ruby's super.

Operator overloading in Perl requires the separate use overload pragma, mapping each operator symbol to a handler subroutine explicitly. Ruby treats operators as ordinary method names from the start — defining a method literally named + is all that is needed to make + work on custom objects, and to_s (Ruby's built-in stringification hook) plays the same role as Perl's '""' overload without a separate pragma to opt into.

die is Perl's raise; a bare eval { } block is the try-block equivalent of Ruby's begin/rescue/end. The key ergonomic difference is how the caught error is exposed: Perl stashes it in the global variable $@ after the eval block ends, which must be checked manually and is easy to forget or accidentally clear with a subsequent eval; Ruby's rescue => error binds the exception object directly to a local variable at the point of the rescue clause, with no global state involved.

Ruby's warn is functionally identical to Perl's warn — both print a message to STDERR and allow execution to continue, unlike die/raise, which stop the program (or the enclosing eval/begin block). Perl appends a file-and-line-number suffix to a warn message that does not end in a newline; Ruby has no equivalent auto-suffix behavior, so the message prints exactly as given.

The ubiquitous Perl idiom open(...) or die "message: $!" exists because many core Perl functions signal failure by returning a false value rather than raising an exception — $! then holds the OS error string (errno). Ruby methods like File.open raise a real exception directly (Errno::ENOENT, for example) rather than returning false, so the or die pattern has no Ruby counterpart: exceptions are the standard way to signal failure throughout Ruby's standard library, not just an option a caller opts into with or die.

Perl can die with a blessed object instead of a plain string, and the caller must manually check ref($error) && $error->isa('AppError') to determine what was thrown. Ruby has a dedicated exception hierarchy rooted at StandardError/Exception, and rescue AppError => error filters by class directly in the rescue clause syntax — no manual isa check needed, and multiple rescue clauses can catch different exception classes in sequence, trying each in order.

Perl has no dedicated "always run this" block keyword — guaranteed cleanup requires either a nested eval with careful manual saving of $@ before it can be overwritten by a subsequent statement, or a module like Scope::Guard. Ruby's ensure clause is a first-class part of begin/rescue/ensure/end (and works the same way appended directly to a def, as shown here): the ensure block always runs, whether the method succeeded, raised, or even used return early, with no manual state juggling required.

Perl's three-argument open takes a mode string ('>' for write, '>>' for append, '<' for read) and a lexical filehandle, and requires an explicit close when finished (or relies on the filehandle going out of scope). Ruby's File.write is a one-line convenience method for the common "write this whole string to this path" case; for finer control, File.open(path, "w") { |file| ... } mirrors Perl's explicit-handle style but auto-closes the file when the block ends, with no explicit close call needed. Both examples are marked norun because the sandboxed execution backends for both languages have no real filesystem.

Perl reads a file line by line with the diamond operator <$filehandle> inside a while loop, and "slurping" the whole file at once requires the somewhat obscure trick of localizing $/ (the input record separator) to undef. Ruby has two direct, purpose-built methods instead: File.foreach for line-by-line iteration, and File.read to slurp the entire contents into one string — no special-variable manipulation needed for either case.

Perl's $_ is a pervasive implicit topic variable: many built-in functions (uc, print, chomp) operate on it when called with no argument, and constructs like for, map, and grep set it automatically for each element. Ruby has no equivalent implicit variable — every block explicitly names its parameter (|word|), which is more verbose for quick one-off transformations but means there is never any ambiguity about which value a bare method call is operating on.

Perl's @ARGV array and %ENV hash have near-identical Ruby counterparts: ARGV (an Array) and ENV (a Hash-like object), both writable in Ruby just as in Perl. The main difference is again the sigil: Perl's special variables carry @ and % prefixes like any other array or hash, while Ruby's equivalents are simply named constants — ARGV and ENV — accessed with ordinary method and index syntax.

Perl exposes process identity through terse punctuation variables: $0 for the script name, $$ for the process ID. Ruby provides the same information through more self-describing names: $PROGRAM_NAME (also aliased as $0 for Perl-familiarity), Process.pid, and the constant RUBY_VERSION — all readable without needing to look up what a bare punctuation mark means.

CPAN (the Comprehensive Perl Archive Network) predates RubyGems, npm, and pip by roughly a decade and pioneered the idea of a centralized, versioned package archive with a consistent module-distribution format — a direct ancestor of the modern package-manager landscape. RubyGems plays the same role for Ruby, typically paired with Bundler and a Gemfile to pin exact versions for a project, a workflow CPAN later adopted its own equivalents for (cpanfile, Carton). Both ecosystems are vast, but Ruby's standard library ships more "batteries included" (JSON support, for example, needs no external dependency) where Perl more often reaches for a CPAN module even for common tasks.