Dart.CodeCompared.To/Ruby

Ruby scripts run top to bottom with no entry function — puts "Hello, World!" is a complete program. There are no semicolons, no type declarations, and parentheses on a method call are optional. puts prints with a trailing newline; p prints a value's inspected form (useful for debugging), and print omits the newline.

A Ruby method declares no parameter or return types, and describe accepts literally any object. This is duck typing: if a value responds to the methods you use, it works; if it does not, you get a NoMethodError at the moment that line runs — not at compile time, because there is no compile time. The freedom is enormous and the safety net Dart gives you is gone.

Every Ruby method returns the value of its last evaluated expression, so an explicit return is rare (reserved for early exits). Ruby 4.0's one-liner "endless method" def cube(n) = … is the near-twin of Dart's arrow body. Because almost everything is an expression — if, case, and blocks all return values — this implicit-return style reaches much further than in Dart.

Ruby interpolates with #{…} inside double-quoted strings — one form for both a variable and a full expression, where Dart offers $name and ${…}. Single-quoted Ruby strings do no interpolation and no escape processing (except \\ and \'), so they are the literal-text choice.

In Ruby there are no primitives: 3 is an Integer object, and 3.times { … } calls a method on it. Even operators are methods — 1 + 2 is 1.+(2) — which is why you can define + on your own classes (shown later). This uniform "everything is an object receiving messages" model has no Dart equivalent, where numbers behave like values with special syntax.

Where Dart's null is a tracked absence the compiler reasons about, Ruby's nil is a singleton object (the sole instance of NilClass) with real methods: nil.to_s is "", nil.to_a is []. That makes many nil values harmless in practice — but calling a method nil does not have still raises NoMethodError at run time, which the next section guards against.

Ruby has no compile-time null safety — nothing stops you from calling a method on a value that turns out to be nil. The runtime tools rhyme with Dart's: &. is the safe-navigation operator (?.), and ||/||= stand in for ??/??=. The catch is that || falls back on nil and false (and nothing else), so it is not a precise null check — which the truthiness rules below make important.

This is a classic trap for anyone from a stricter language. In Ruby every value is truthy except nil and false — so 0, "", and [] are all true. Dart, by contrast, requires a genuine bool in a condition and would reject if (count). Guard for emptiness explicitly (count.zero?, text.empty?) rather than leaning on truthiness the way you might elsewhere.

Ruby has no final/var distinction. A name's role comes from its case: MAX_RETRIES is a constant because it is capitalized, a lowercase name is a local variable. Reassigning a constant only prints a warning rather than failing, so the immutability is a convention the compiler cannot enforce — very different from Dart's checked final. Prefixes also carry meaning: @name is an instance variable, $name a global.

A Symbol (:active) is an immutable, interned identifier with no Dart counterpart — the same symbol is always the exact same object, which makes symbols the idiomatic choice for hash keys, method names, and enum-like constants. They are cheaper and more intention-revealing than strings for those roles, so { active: "On" } (symbol keys) is far more common in Ruby than string keys.

As of Ruby 4.0, string literals are frozen by default, so "hello" << " world" raises a FrozenError. This narrows a historical gap with Dart, whose strings are fully immutable — but Ruby still allows mutable strings on request via the unary + (+"hello") or .dup, and mutating methods like <<, gsub!, and upcase! exist for them. Non-bang methods (upcase) always return a fresh string.

Ruby's naming convention pairs a safe method with a mutating twin marked by a !: sort returns a new array, sort! reorders the receiver in place and returns it. The ! is a "danger, this mutates" flag (also seen on map!, reject!, upcase!). Dart has no such convention — you copy explicitly with the spread operator and cascade, as on the left.

A Dart List is a Ruby Array, untyped and heterogeneous — [1, "two", :three] is fine. Appending is idiomatically << (though push exists), and Ruby's convention is that boolean-returning methods end in ? (include?, empty?, any?). The Array API is vast and mostly comes from the Enumerable module, covered next.

A Ruby Hash is Dart's Map, written with => between key and value ("Ada" => 36), or the key: value shorthand when keys are symbols. A missing key returns nil like Dart, but you can set a default (Hash.new(0)) so lookups never return nil — handy for counting. Iteration uses a block, each { |k, v| … }, rather than a callback.

Ruby's Enumerable is the richest collection library on this site, and the chain maps closely: where is select (aliased filter), map is map, and fold is reduce/inject — though dedicated methods like sum, min, group_by, partition, and each_with_object usually read better. Every one takes a block, the syntax explored next.

A Ruby method can take one block — written { |x| … } for one line or do |x| … end for many — without declaring it as a parameter, and invokes it with yield (or checks block_given? first). Where Dart passes a closure as an explicit argument, Ruby gives blocks their own syntax, which is why File.open(path) { |file| … } reads so cleanly: the method opens, yields, and closes around your block.

When you need to store a block as a value, Ruby gives you two closures: a lambda (->(n) { … }) and a Proc (proc { … }). They are Dart's function values, invoked with .call (or .()). The differences are Ruby-specific: a lambda checks its argument count and returns only from itself, while a Proc is lax about arity and returns from the enclosing method — subtleties Dart's uniform closures never present.

The &:upcase idiom is pure Ruby shorthand: & converts the symbol :upcase into a block that calls that method on each element, so map(&:upcase) means map { |w| w.upcase }. It is the terse form you will see everywhere for "call this one method on everything," with no direct Dart equivalent — Dart requires the full (word) => word.toUpperCase().

This maps almost exactly. Ruby's keyword arguments — def connect(host, port: 5432, tls: true) — are the counterpart of Dart's named parameters with defaults, passed the same way at the call site (port: 6432). A keyword without a default (port:) is required, mirroring Dart's required. Ruby also has positional defaults and a *splat for variadics, covered next.

The * splat operator collects trailing arguments into an array (def sum_all(*numbers)), so callers pass separate values with no list literal — Dart cannot do this. The same * destructures on assignment (first, *rest = …), and Ruby's parallel assignment a, b = 1, 2 covers what Dart records and their patterns do — including the one-line swap a, b = b, a.

Ruby keeps the ternary, but adds two things Dart lacks: the modifier form (puts "pass" if score >= 60) that trails the condition after the statement, and unless as a first-class "if not." Crucially, if is an expression that returns a value, so you can assign its result — one reason explicit returns are so rare in Ruby.

Ruby's case/when matches with the case-equality operator ===, which each class defines: Integer === 42, (1..10) === 5, /ab/ === "abc". That makes a single case dispatch on type, range, or regex — more flexible than Dart's value switch, though Dart 3's type patterns cover the type case. Like if, case returns a value.

Ruby 3 added structural pattern matching with case/in, the close cousin of Dart 3 patterns — it destructures arrays and hashes, binds variables, and checks types in one step (port: Integer => port). Note the two different constructs: case/when (above) tests with === and does not bind, while case/in matches structure and binds, the way Dart's single switch does both.

Ruby has range literals — 1..3 (inclusive) and 1...3 (exclusive) — that Dart lacks, and they are objects you can iterate, convert (to_a), or match in a case. Iteration is done by sending each (or times, upto) a block rather than writing a C-style for; the bare for keyword exists but is almost never used in idiomatic Ruby.

A Ruby class's constructor is the method initialize, called for you by Point.new. Instance state lives in @-prefixed variables (@x), which are private to the object and not declared up front — you simply assign them. There are no type annotations and no this keyword (the receiver is self, usually implicit), so a class body is strikingly terse next to its Dart equivalent.

Instance variables are private in Ruby, so exposing them needs accessor methods — and attr_accessor :name, :age generates both the reader and the name=/age= writer for you (with attr_reader/attr_writer for one direction). It is the counterpart of Dart's public fields and getters/setters, but note person.age = 37 is actually a method call to age=, which is why you can add validation later without changing callers.

Because operators are ordinary methods, you overload one by defining a method named after it: def +(other), and likewise ==, <=> (the "spaceship," which powers sorting), and []. Overriding to_s customizes string conversion the way Dart's toString does. This is the same capability as Dart's operator +, just falling naturally out of "everything is a method."

Ruby's mixins come from modules: a module holds shared methods, and a class pulls them in with include (adding instance methods) or extend (adding class methods). It is the direct ancestor of Dart's with mixins — Dart borrowed the idea — but Ruby modules also serve as namespaces and, via Comparable/Enumerable, as the standard way to get a whole API from one required method.

Where Dart's extension methods are scoped and resolved statically, Ruby lets you reopen any class — even Integer or String — and add or replace methods everywhere, permanently, at run time. This "monkey patching" is enormously powerful (it is how libraries like Rails add 3.days.ago) and correspondingly dangerous: there is no scoping, so a patch affects the entire program. Ruby hands you the keys; use them sparingly.

Ruby has no interface or implements. If an object responds to render, it can be passed to show — that is duck typing, and conformance is never declared. You can ask an object respond_to?(:render) at run time if you must check, but the idiom is simply to call the method and let a NoMethodError surface the mistake. It is the polar opposite of Dart's compile-time interface checking.

Two everyday metaprogramming tools. send(:upcase) invokes a method whose name you hold as a symbol or string — dynamic dispatch chosen at run time — and define_method creates methods programmatically, so the two Widget methods here are written by a loop rather than by hand. Dart has no equivalent: its method set is fixed at compile time, which is safer but far less malleable.

When an object receives a message it has no method for, Ruby calls method_missing before failing — letting you intercept arbitrary calls and respond dynamically. Here it fakes name/name= accessors that were never defined. This is how libraries build fluent, schema-free APIs (record.any_column_name), and it has no counterpart in Dart, where an unknown method is simply a NoSuchMethodError.

The keywords rename but the structure is familiar: raise throws, rescue ClassName => error catches by exception class (Dart's on Type catch), and ensure is finally. Inside a method you can drop the begin/end and put rescue in the method body directly. Ruby also has retry to re-run the begin block — useful for transient failures, with no Dart equivalent.

A custom Ruby exception is a class that inherits from StandardError (the base you should rescue, not the broader Exception). Calling super("…") sets the message that error.message returns. It parallels Dart's "implement Exception and override toString," but through ordinary inheritance — and the convention of rescuing StandardError rather than everything is worth internalizing.

Ruby loads code with require (for installed libraries and gems) or require_relative (for files by relative path), executed as a statement at run time rather than resolved statically like Dart's import. A required library's names land in the global namespace unless it defines a module to scope them — there is no per-import prefix like Dart's import … as math by default.

Ruby packages are gems, declared in a Gemfile and installed by Bundler (bundle install) — the direct analog of pubspec.yaml plus dart pub get. Gems come from rubygems.org, and the version-constraint syntax rhymes: Ruby's pessimistic operator ~> 4.0 plays the role of Dart's caret ^1.2.0, allowing compatible updates but not breaking ones.