Elm.CodeCompared.To/Ruby

Ruby is statement-oriented and effect-first: puts writes straight to standard output, which this column captures as text. Where Elm describes a value for the runtime to render, Ruby just performs the side effect on the spot.

Ruby writes a line comment with #; its block comment is the =begin/=end pair, which — unlike Elm's {- -} — must start in the first column and cannot nest. Ruby has no dedicated documentation-comment syntax the way Elm has {-| ... -}.

Ruby has no let and no block scope for locals — a variable simply springs into being on assignment and stays reassignable. Nothing marks it immutable, so the discipline Elm enforces is left to convention here.

Ruby has no inline type annotations and no compile-time checking; a method just takes whatever it is given. Optional .rbs signature files plus a tool like Steep can add external checking, but nothing in the language requires it. This also shows Ruby's "endless" one-line method (def name(...) = expression), the closest match to Elm's single-expression bodies.

Ruby infers nothing and checks nothing ahead of time — a type mismatch surfaces only when the offending line runs, if it runs at all. In exchange, everything is genuinely an object: even 42 and nil have methods (42.even?, nil.to_s). The p method prints any value's inspect form, filling the role of Debug.toString.

Ruby also distinguishes Integer from Float, but chooses the operation by the operands rather than the operator: 7 / 2 is integer division (3) because both are integers, and you ask for a float result with 7.fdiv(2) or 7.0 / 2. Mixing the two never fails to compile — there is no compile step — so a stray .0 silently changes the answer.

Ruby exposes the same operations as methods called on the string object — "hello".upcase, "hello".length — because in Ruby a string is an object with behavior, not a value acted on by a separate module. In Ruby 4.0 string literals are frozen by default, so upcase returns a new string rather than mutating in place, matching Elm's immutability.

Ruby interpolates with #{...} inside a double-quoted string and silently calls to_s on whatever you embed — so the integer year needs no explicit conversion. That convenience is exactly what Elm withholds on purpose: its explicit String.fromInt guarantees you never coerce a value by accident.

Ruby spells these as methods chained off the value — split returns an Array and join folds it back to a String. Method chaining reads much like Elm's |> pipeline, but only for methods the receiving object actually defines, whereas |> threads a value through any function.

Ruby's if is also an expression — the method returns the chosen branch with no return needed, a rare point of agreement with Elm. The difference is that Ruby's else is optional: an if with no matching branch evaluates to nil, and the branches need not share a type, so nothing rules out the "missing else" that Elm forbids.

Ruby treats every value as a boolean in a condition, and — unlike JavaScript — only nil and false are falsy, so 0 and "" are truthy. Its &&/|| return one of their operands rather than a strict Bool, which enables idioms like value || default. Elm rejects all of this: a condition must be an actual Bool.

Ruby uses nil for a missing value, and value || default supplies a fallback much as Maybe.withDefault does. The crucial difference is that nil is not a distinct type: any value can be nil, and nothing forces you to handle that case, so a forgotten check becomes a NoMethodError on nil at runtime — the very class of bug Maybe makes impossible.

Ruby's safe-navigation operator &. calls a method only when the receiver is non-nil, so name&.upcase mirrors Maybe.map String.toUpper. But Array#first returns a bare nil on an empty array rather than a Nothing you are required to handle, so remembering the &. is on you — the emptiness is invisible in the type.

Ruby threads possible absence by hand: Integer(raw, exception: false) returns nil instead of raising on bad input, and the following number && ... short-circuits so nothing is called on nil. It works, but nothing composes the steps for you the way Maybe.andThen does, and no type records that the result can be missing.

Ruby chains methods on the collection itself — select is Elm's List.filter and map matches directly. Each returns a new array, so the pipeline never mutates the original; the block { |number| ... } is Ruby's inline anonymous function, and number.even? replaces modBy 2 n == 0.

Ruby's reduce (also spelled inject) is the counterpart to List.foldl, with the accumulator passed first into the block. You can even hand it a bare operator as a symbol — reduce(:+) — echoing Elm's (+). For summing specifically, the purpose-built sum is the idiomatic choice.

Ruby's Hash holds keys of any type at once and returns a bare nil for a missing key with [], rather than the Maybe that Elm's Dict.get forces you to unwrap. Use fetch when a miss should raise or take an explicit default. A Hash is also freely mutable, unlike an Elm Dict.

Ruby has no tuple type; it returns an Array and relies on parallel assignment (quotient, remainder = ...) to take it apart. The syntax is nearly identical to Elm's, but an array carries neither a fixed length nor per-position types, so the shape of the return value is not guaranteed the way a ( Int, Int ) is.

Ruby's sort also uses the elements' natural order — numbers compare numerically, with none of JavaScript's convert-to-string surprise — and returns a brand-new array, leaving the original untouched, just as Elm does. (The in-place variant sort! is the mutating exception Ruby offers and Elm does not.)

Ruby's closest match to an Elm record is Data.define (Ruby 3.2+), which builds an immutable value object with named readers. It is a much tighter fit than a plain Hash: instances are frozen and compared by value. What it does not give you is field-level type checking — age can hold anything — nor a compile error for reading a field that does not exist.

A Data object is immutable, so it offers with — the direct analog of Elm's record-update syntax, returning a fresh copy with some fields changed and the original intact. Like Elm's form it only sets fields that already exist, so a misspelled name raises rather than quietly adding a field.

Ruby has no enum type; the idiomatic stand-in is a symbol — an interned, identity-compared name like :red — matched with case/in. But the set of symbols is open and unchecked: forgetting :green is not a compile error, it is a NoMatchingPatternError raised at runtime, so exhaustiveness is a hope rather than a guarantee.

Ruby models a tagged union as one Data class per variant, and — because Data supports deconstruction — case/in can match the class and pull out its fields in a single pattern, e.g. in Circle(radius:). It reads remarkably like Elm's case, but the variants are unrelated classes with no shared parent type, and the match is still checked only at runtime.

Ruby 3's case/in brings real structural matching: array patterns like [only] and [first, *rest] line up almost exactly with Elm's [ only ] and first :: rest, binding as they match. The gap is exhaustiveness — Ruby will not warn that a shape is unhandled, and an unmatched value raises at runtime instead of failing to compile.

Ruby matches nil as a literal pattern and binds anything else with a variable pattern like found. It captures the two Elm branches, but note the asymmetry: Just "Ada" and Nothing are two constructors of one type, whereas Ruby is matching a value that happens to be a string against one that happens to be nil, with nothing tying them into a single Maybe.

Ruby's hash patterns match by key and bind the values ({ x:, y: } binds x and y), and a trailing if adds a guard — a test Elm would push into an if inside the branch. Ruby also offers a plain else for the fall-through, where Elm insists every case be covered by a pattern.

Ruby's "endless" method (def add(...) = expression, added in 3.0) matches Elm's single-expression style closely. A conventional def ... end body also returns its last expression with no return keyword needed. Ruby does wrap parameters in parentheses and separates arguments with commas at the call site — add(2, 3) — where Elm uses spaces.

Ruby writes a lambda as ->(number) { ... }, a first-class object you can store and pass around like any Elm function. Passing it where a block is expected takes an explicit & (map(&triple)), because Ruby draws a line — which Elm does not — between an ordinary object argument and the single "block" a method may receive.

Ruby gives every method one special implicit callback — the block — invoked with yield and written in { } or do ... end after the call. It is the idiom behind each, map, and friends. Elm has no such special slot: a function argument is passed and named like any other (applyTwice f x), which is why Elm needs no yield.

Ruby methods are not curried by default — add(10) would be an argument-count error — so partial application is opt-in: Proc#curry turns a lambda into one that accepts its arguments one at a time, and add.curry[10] then reads like Elm's add 10. Where currying is the default in Elm, it is an explicit tool in Ruby.

Ruby borrows the very same operator: Proc#>> composes two callables left-to-right, so reverse >> shout reverses then upper-cases exactly as in Elm (and << composes the other way). The one catch is that composition works on Proc/lambda objects, so a plain method must first be wrapped with method(:name).

Ruby supports the same recursive definition, but unlike Elm it also offers real mutable loops (while, for, times) and mutation, so idiomatic Ruby often reaches for iteration or a method like reduce instead. Ruby does not guarantee tail-call optimization, so very deep recursion can overflow the stack where a rewritten loop would not.

Ruby signals failure the way Elm deliberately avoids: it raises an exception that unwinds the stack until a begin/rescue catches it. The failure is control flow, not a value, so it never appears in a signature and a caller can simply forget to rescue — whereupon the error escapes to the top level. Elm makes the failure an ordinary Result value the caller is forced to handle.

Ruby's inline rescue modifier supplies a fallback when an expression raises — here Integer("20") succeeds, but a non-numeric string would be rescued to "not a number", playing the role of Result.withDefault. It is compact, but it recovers by catching a stack unwind rather than by threading an Err value through the computation, and it will swallow any StandardError, not just the one you had in mind.

Elm's HTML is a typed value — div [ attributes ] [ children ] — that the runtime turns into DOM. On the Ruby side, ERB is a text template with <%= %> holes producing an HTML string (the Rails server model), while Phlex builds the same markup with pure-Ruby method calls — div { h2 { … } } — which reads much like Elm's view and takes its attributes as an ordinary Ruby Hash (style: { padding: "16px" }). Both run in Ruby and are shown live in the pane.

ERB embeds real Ruby: <% fruits.each %> loops and <%= fruit %> interpolates. Phlex writes the same loop as ordinary Ruby inside the view — fruits.each { |fruit| li { fruit } }. Elm has no template language at all: iteration is just List.map producing a list of li elements.

The view reacts to the data: each task's color and marker are computed from its done field. Elm folds the decision right into the attribute value because its if is an expression; ERB drops a Ruby ternary into a <%= %> hole; Phlex writes the ternary inline in ordinary Ruby. The Data.define record stands in for Elm's type alias Task.

Reuse is just a function in Elm — badge is a function returning Html, called wherever a badge is needed. Phlex matches this most closely: a Badge component is nested with render, and plain emits bare text. ERB has no component model, so reuse falls to a helper method that returns an HTML string, which the outer template interpolates raw.

Elm's text always escapes its content, so injected markup can only ever render as inert characters — cross-site scripting is impossible by construction. Phlex takes the same safe-by-default stance: block text is escaped automatically. Plain ERB is the outlier — <%= %> emits raw HTML, so you must call ERB::Util.html_escape yourself (Rails' ERB flips this to auto-escape, which is why the framework, not the language, is what makes Rails views safe).