Ruby.CodeCompared.To/Elm

Elm has no puts and, in fact, no statements at all. You define main as an expression, and the runtime renders whatever it evaluates to — here the value text "Hello, World!", which this column scrapes as text. Where Ruby performs output as an action, Elm describes a value and lets the runtime do the effect, the first sign of its rule that ordinary functions never have hidden side effects.

Elm's line comment is -- and its block comment is {- ... -}, which — unlike Ruby's =begin/=end — can sit anywhere on a line and can nest, so you can comment out a block that already contains a block comment. Elm also has a documentation-comment form, {-| ... -}, that its tooling understands, where Ruby layers the separate RDoc/YARD conventions on top of ordinary # comments.

Elm names intermediate values in a let ... in block, and every binding is immutable — a name is bound once and never reassigned. There is no free-floating assignment the way Ruby has: each let binding exists to feed the single expression after in. The discipline Ruby leaves to convention (don't reassign unless you mean to) is simply the only option Elm gives you.

The line initials : String -> String -> String above the function is its type signature — "takes two strings, returns a string". Elm checks every such signature before the program runs, so passing a number here is a compile error, not a runtime surprise. Ruby can add comparable checking externally with .rbs files plus a tool like Steep, but nothing in the language requires it; in Elm the type is part of the code and the compiler is never optional.

With no annotation written, Elm still works out the exact type of every value here — a list of strings in, a list of ints out — and checks it before the program runs, giving full type safety with almost none of the ceremony of writing types out. That is the Ruby trade reversed: Ruby gives you objects with behavior everywhere (42.even?, nil.to_s) at the cost of catching type errors only at runtime, while Elm gives up that runtime flexibility to catch every type error up front. Debug.toString fills the role of Ruby's p.

Elm has no mutation anywhere: cart can never change, so "adding" an item means building a brand-new list with ++ and giving it its own name. This removes an entire category of Ruby bug — the aliasing surprise where two variables point at the same array and a push through one is silently seen through the other. In Elm, a value you hold is a value you can trust never to change under you.

Elm has no open classes and no monkey-patching — you cannot add a method to Int, and there are no classes to reopen. New behavior is always a plain function you define in your own module, such as minutes here, and call explicitly as minutes 5. The convenience of 5.minutes is real, but so is its cost: a value's abilities can be changed from anywhere, by any loaded gem. In Elm, where a function comes from is always visible at the call site, so nothing is ever bolted onto a type behind your back.

Elm keeps Int and Float as separate types with separate operators: // is integer division and / is float division, and it refuses to mix the two — dividing the ints with / would not compile until you convert them with toFloat, as shown. Where a stray .0 in Ruby silently switches you between integer and float division at runtime, Elm forces the choice into the operator and the conversion, and checks it before the program runs.

Elm's string tools are functions in the String module, not methods on the value — String.trim, String.toLower — because an Elm string is plain immutable data, not an object that carries behavior. Chaining them with the pipe operator |> reads much like Ruby's raw.strip.downcase, but the same |> would thread the value through any function, not only ones the string happens to define. Immutability is the default here rather than the Ruby 4.0 opt-in.

Elm has no string interpolation: pieces are joined with ++, and a number must be converted with String.fromInt before it can join a string. That verbosity is deliberate — the automatic to_s coercion Ruby does for you is exactly the kind of implicit conversion Elm withholds, so you never accidentally stringify a value you did not mean to. What you gain for the extra keystrokes is that no value is ever coerced behind your back.

Elm spells these as ordinary functions — String.split and String.join — threaded together with the pipe operator |>, which feeds each result into the next function. Ruby's method chaining reads much the same, but it works only for methods the receiving object defines, whereas |> threads a value through any function, so the same operator composes split, join, and your own helpers uniformly.

Elm's if is an expression too — a rare point of agreement — but with two rules Ruby lacks: it always needs an else, and every branch must produce the same type. That is because the if yields a value the rest of the program consumes, so there can be no "missing branch" quietly evaluating to nil, which is exactly what a Ruby if with no matching branch does. The mandatory else is the compiler closing a gap Ruby leaves open.

Elm has no truthiness at all: &&, ||, and not accept only the Bool type, and a condition must be an actual Bool — there is nothing else a value in that position could be. The Ruby idioms that lean on truthy/falsy values (value || default, guarding on a possibly-nil object) simply do not typecheck here; their jobs move to Maybe and explicit comparisons. In return you never puzzle over whether some value counts as true.

Elm has no null and no nil. A value that might be missing has the type Maybe — either Just x or Nothing — and Maybe.withDefault plays the role of || default. The decisive difference is that absence is written into the type: the compiler will not let you use the name until you have handled the Nothing case, so the forgotten check that becomes a NoMethodError on nil in Ruby is a bug Elm makes impossible to write.

Maybe.map reaches inside a Just to transform its value and leaves a Nothing untouched — the direct analog of tags.first&.capitalize, with no unwrapping and no nil check. The gap is that List.head returns a Maybe String, so the emptiness is visible in the type and the compiler makes you deal with it, whereas Ruby's first hands back a plain nil and remembering the &. is on you. (Note there is no built-in capitalize; behavior lives in functions you write.)

When one step's result can itself be missing, Maybe.andThen chains the steps and stops at the first Nothing, so the pipeline composes cleanly instead of nesting && guards. Ruby's version works, but nothing links the steps for you and no type records that the result can be missing — you must remember, at every call site, that parse_port might return nil. Elm's Maybe Int return type carries that warning everywhere it goes.

Elm expresses the same pipeline with the pipe operator |> feeding a value into each function in turn — List.filter is Ruby's select, List.map matches directly, and the lambda \price -> ... is the block. The functions live in the List module rather than on the value, and there is no method chaining, since lists are data, not objects. Like Ruby, every step returns a fresh list and the original is untouched — the difference is Elm guarantees that, where Ruby merely offers it.

Elm's List.foldl is the counterpart to reduce, folding from the left with an accumulator. Note (+): wrapping an operator in parentheses turns it into an ordinary function you can pass as an argument, exactly the way Ruby lets you hand reduce a symbol with reduce(:+). The idea is identical; Elm just treats operators as first-class functions by default rather than needing the :symbol shorthand to pass one.

An Elm Dict is an immutable key–value map, and — because a key may be absent — Dict.get returns a Maybe you must unwrap, rather than the silent nil that Ruby's [] hands back. Two constraints come with the safety: all keys share one type (no mixing strings and symbols in one Dict), and it cannot be mutated in place — updating produces a new Dict. The fetch-with-default habit you have in Ruby is essentially Dict.get followed by Maybe.withDefault.

Elm has a real tuple: a fixed-size group of values, each possibly a different type, taken apart by pattern — the idiomatic way to return two results. The destructuring ( first, last ) = ... reads almost exactly like Ruby's parallel assignment, but the type ( String, String ) guarantees the shape: always two values, always those types. A Ruby array return makes no such promise, so a caller expecting two values from a method that later returns three finds out only at runtime.

List.sort orders a list by the natural ordering of its element type, so a list of numbers sorts numerically on its own, with none of JavaScript's convert-to-string surprise — the same well-behaved result as Ruby's sort, and likewise a fresh list rather than a mutation. The one thing Elm cannot offer is the in-place sort! variant: with no mutation in the language, sorting can only ever return a new list, never rearrange the one you passed in.

An Elm record is a value with named fields whose set and types are fixed and known to the compiler, declared as a type alias. It lines up neatly with Data.define — both immutable, both accessed by field name — but Elm adds two guarantees Ruby cannot: each field has a declared type (price can only ever be an Int), and reading a field that does not exist is a compile error rather than a NoMethodError discovered when that line finally runs.

Because nothing mutates in Elm, "updating" a record means building a new one with the { record | field = ... } syntax — the direct analog of Data#with, producing a fresh copy while the original stays put. Like with, it can only set fields that already exist, so a misspelled field name is caught rather than quietly creating a new one. The gain over Ruby is that Elm catches the typo at compile time, where with raises only when the line runs.

A type in Elm lists a fixed set of named alternatives — a real enum for this order-status machine — and the compiler checks that every case handles all of them. That is the guarantee Ruby symbols cannot give: because the set of symbols is open, forgetting :delivered is not an error but a NoMatchingPatternError raised at runtime, so exhaustiveness is a hope. In Elm, adding a fourth status makes the compiler flag every case that has not yet handled it — the feature that lets Elm programs change safely.

Elm builds this into one type: each alternative of a custom type can carry its own data, so Payment is either a Cash or a Card, and a single case both selects the variant and destructures its data. The Ruby version reads similarly, but its Cash and Card are separate classes with no common parent — nothing stops a third payment kind from slipping past the case unhandled. Elm's one Payment type makes the set closed and the match exhaustive, checked before the program runs.

Elm's case picks a branch by matching a value's shape, and its patterns line up almost exactly with Ruby's — [ only ] mirrors [only], and the head-and-tail first :: rest mirrors [first, *rest]. The difference is exhaustiveness: the Elm compiler checks that the empty, single, and many cases together cover every possible list and refuses to build if one is missing, whereas Ruby happily compiles a case with a hole and raises a NoMatchingPatternError only when a stray value reaches it.

Because Maybe is an ordinary custom type, one case handles its Just and Nothing branches directly. The contrast with the Ruby version is subtle but important: Just "Ace" and Nothing are two constructors of a single Maybe type the compiler tracks, whereas Ruby is matching a plain string against a plain nil with nothing tying them into one type — so nothing in Ruby guarantees the value even could be only those two things, or that you handled both.

Elm mixes the exact pattern 200 with the binding pattern other that matches everything else. Elm's case has no guard clause, so the range tests Ruby writes as trailing if conditions move into an if inside the branch — a small readability trade for the guarantee that every value is covered by a pattern. Where Ruby leans on a catch-all else, Elm prefers a binding pattern like other that provably matches everything the earlier patterns did not.

An Elm function uses no def keyword, no parentheses around its parameters, and no return: the body is a single expression, much like Ruby's endless method. The visible differences are at the edges — Elm separates a function from its arguments with spaces (fullName "Ada" "Lovelace") rather than parentheses and commas, and carries the String -> String -> String signature above it. The chain of arrows in that signature is not decoration; it is what makes the currying two examples down possible.

An Elm anonymous function is introduced by a backslash before its parameter — \bill -> ... — and is just a value, passed to List.map like any other. There is no & and no distinction to bridge, because Elm has no separate notion of a "block": a function is a function wherever it appears. That single uniform idea is why Ruby's split between an ordinary argument and the one special block a method may receive simply does not exist here.

In Elm you pass one function to another as an ordinary value — keepIf names its function argument predicate and hands it straight to List.filter, so there is no yield and no special block slot. The signature spells the contract out: (Int -> Bool) -> List Int -> List Int says the first argument is itself a function from Int to Bool. What Ruby makes ergonomic with a dedicated block, Elm makes uniform by having only one kind of callable.

Every Elm function takes its arguments one at a time, so applying multiply to a single value yields a new, more specific function — multiply 2 is "double", no ceremony required. Partial application is therefore free and pervasive where in Ruby it is a deliberate tool you reach for with curry. This is what those chained arrows in the signature meant all along: Int -> Int -> Int is really Int -> (Int -> Int), a function that returns a function.

Elm has the very same >> operator, joining two functions into one that runs the first and passes its result to the second (and << composes the other way) — String.trim >> String.toLower trims then lower-cases. Ruby borrowed this operator, and it works the same, with one asymmetry: in Elm every named function is already a plain value, so there is no method(:name) wrapping step — String.trim composes directly.

Elm has no for or while loop and no mutation, so a repeated computation is written as a function that calls itself — recursion is not a stylistic preference here but the mechanism. For most real work you reach for List.map and List.foldl instead of hand-written recursion, just as you would prefer reduce over a manual loop in Ruby. Elm guarantees tail-call optimization for functions written in tail position, so a properly shaped recursive loop will not overflow the stack the way a deep Ruby recursion can.

Elm has no exceptions at all. A computation that can fail returns a Result — Ok value on success, Err reason on failure — so the failure is an ordinary value the type records and the caller is forced to handle. That closes the gap Ruby leaves open: a Ruby caller can simply forget to rescue, and the exception escapes to the top level, whereas an Elm caller cannot get at the balance without first dealing with the Err. Failure moves from invisible control flow into the function's signature, in plain sight.

Result.map transforms a success value and carries any earlier Err straight through untouched, so a whole pipeline runs with no nested checks and stops at the first failure. Compared with Ruby's rescue, the difference is precision: Elm threads a specific Err "not a number" value through the computation rather than catching whatever exception happened to fly by, so it can never accidentally rescue an unrelated error. The failure is handled by data flow, not by unwinding the stack.

Elm's HTML is a typed value, not a template: div [ attributes ] [ children ] is an ordinary function call the runtime turns into real DOM. Where ERB is a text template with <%= %> holes — the familiar Rails server model — Elm has no template language at all, so the same building blocks (elements, attributes, children) are just nested function calls. Attributes are a list and children are a list, which is why the whole view reads as data you assemble rather than markup you fill in.

ERB embeds real Ruby — <% posts.each %> loops and <%= post %> interpolates each value into the surrounding text. Elm needs no template directives because iteration is just List.map producing a list of li elements, which becomes the children list of the ul. Building markup and building a list are the same operation in Elm, so the ordinary list functions you already met are also the whole templating story.

The view reacts to the data: each feature's color and marker are computed from its enabled field. ERB drops a Ruby ternary into a <%= %> hole; Elm folds the same decision directly into the attribute value, since its if is an expression that produces a value. The type alias Feature plays the exact role of the Data.define record, but Elm also knows at compile time that every feature has an enabled boolean, so a view that read a missing field would not build.

Reuse in Elm is just a function: navLink takes a label and returns Html, called wherever a link is needed — the same instinct as an ERB helper that returns a markup string, but returning a typed value rather than text. Because a component is an ordinary function, it composes with all the tools you have seen: you could List.map navLink over a list of labels, pass it around, or nest it inside another view, with no separate partial or template-lookup mechanism.

Elm's text function always escapes its content, so injected markup can only ever render as inert characters — cross-site scripting is impossible by construction, with nothing to remember. Plain ERB is the opposite default: <%= %> emits raw HTML, so you must call ERB::Util.html_escape yourself, and it is Rails (not the language) that flips ERB to auto-escape. Where Rails makes safety a framework convention layered on top, Elm bakes it into the one function you use to put text on the page.

This is the heart of The Elm Architecture: a Model holding all state, a Msg type listing everything that can happen, and an update : Msg -> Model -> Model that returns a new model for each message. Because nothing mutates, applying a stream of messages is exactly a List.foldl — the same fold you met with lists, now folding over events. A Rubyist knows this shape as a reducer; the difference is that in Elm it is not one pattern among many but the way every application is structured, and the exhaustive case guarantees no message is left unhandled.

Browser.sandbox wires the three pieces — an initial model, the update from the previous example, and a view : Model -> Html Msg — into a self-contained live application. The runtime holds the state, hands each click to update, and re-renders the view, all on the client with no page reload. That is the deep contrast with the Ruby sketch: the Rails/Sinatra model round-trips to the server and mutates a variable to change state, while Elm keeps the whole loop in the browser and never mutates — each click produces a new model. Redux and much of modern front-end state management are this architecture, borrowed from Elm. Both sides are display-only here.