Swift.CodeCompared.To/Roc

The _args parameter is named with a leading underscore because it is required by the signature and unused — the same convention Swift uses for an ignored closure parameter. Ok({}) is the return value, where {} is the empty record: Roc's Void.

The difference is that the list is checked. A Roc application cannot reach for an effect its platform does not provide, so there is no equivalent of code that builds on Darwin and fails to link on Linux because Foundation is a different library there.

Because the exit status is the function's return value, the compiler type-checks it. There is no way to call exit from deep inside a library and skip every defer on the way out.

The count : I64 line is a type annotation on its own line above the definition, rather than after the name as in Swift. Writing it is optional, but it pins down which number type this is — and that decides what gets printed.

Roc convention is to annotate top-level functions anyway, for the same readability reason Swift requires it — and the compiler checks the annotation against the inferred type rather than taking it as the definition. There are also no argument labels, so the call site is bare.

Point here is an alias, not a struct — nothing is constructed and no name appears at the call site. When you want Swift's nominal behavior, := instead of : gives it to you; see the newtype row in Gotchas.

The Roc version has two cases and needs no fallback, because its type says there are exactly two. The Swift version needs a third branch for everything it was not designed for, and that branch is where a mistake lands silently.

The practical difference is that a Roc "nothing" can say which nothing. Missing, NotYetLoaded and Refused are three distinct values in the same union, where Swift would have one nil for all three and a comment explaining which is meant.

The implicitly-unwrapped optional (String!) is the same hatch widened, and it exists mostly for Objective-C interoperation and for outlets set after initialization. A language with neither of those does not need it.

The difference is what it unwraps. Swift's ?? takes an Optional, which can only say "nothing"; Roc's takes a Try, whose Err side could have carried a reason that ?? chooses to discard. Everything else about the row is identical, which is why this is the easiest transition on the page.

The Roc column is longer, and that is the honest trade: ?. chains are genuinely concise. What they hide is that each link silently short-circuits the whole expression, so a nil two levels down and a nil at the top are indistinguishable at the end — the match version has to say which.

The Swift column shows the decision costing something: the same two lines mean opposite things depending on which keyword was used three lines earlier. In Roc there is one kind of value and no keyword to choose, and the compiler still avoids the copy whenever it can prove nobody else holds the original.

Shadowing is unavailable too, which is stricter than let in a nested scope. Each step of a calculation gets its own name, so a variable cannot quietly mean something different fifteen lines further down.

A var is local to its function and cannot escape it, so there is no stored property to mutate, no inout parameter, and no mutating func — the three places Swift lets mutation cross a boundary.

Swift has to name each property twice to unpack a struct, which is why struct-to-local unpacking is rare in Swift code. Matching by name also means reordering two fields cannot silently swap them, which positional destructuring permits.

The syntax is a little denser in Roc — one line for the union, and no let inside the pattern — and the substance is the same. What Roc adds is in the next three rows: no declaration required, and unions that can stay open.

Swift needs the enum declaration before either use. The exhaustiveness guarantee is identical — both compilers reject a missing case — but getting it without a declaration changes how readily you reach for a union at all, for a two-state value that would otherwise become a Bool.

This has no Swift equivalent. An enum is exhaustive precisely because it is closed — the @unknown default case exists only for library-evolution enums you do not own — so "these two, plus whatever turns up" means Any and losing the check on the two you named.

Roc works out where a pointer is needed and inserts it. That is a small convenience here and a real one in a large type, where indirect has to be applied to the enum or to each recursive case and forgetting it is a compile error about infinite size.

The one asymmetry is what a match is. Every Roc match is an expression producing a value, so the arms must agree on a type; a Swift switch is a statement, which is why the enum row above needs a return per case or a pre-declared let.

What Roc adds is Dec, a fixed-point decimal type with no Swift equivalent outside Foundation's Decimal. What it removes is Int and UInt, the word-sized defaults, so every integer in a Roc program has a width you can name.

Decimal is the Swift answer and it costs a Foundation import, a failable string initializer, and a decision at every arithmetic site. Here the difference between the two Roc lines is one annotation.

That decision is the trap: 17 / 5 and 17.0 / 5.0 are different operations spelled almost identically, and changing a variable from Int to Double silently changes which one runs. Two operators cannot be confused that way.

The Swift column uses addingReportingOverflow so it can print rather than trap, which is the same shape as a Roc Try: a value plus a report, instead of a crash. This is one of the closest agreements between the two languages.

Swift's interpolation accepts anything and calls its description or reflects over it, which is how a struct's default reflection output ends up in a user-facing message. "${age}" in Roc is a type error naming I64 where Str was expected.

Swift already refuses to add a number to a string, so both languages make you convert. The difference is only which spelling: String(5) against 5.to_str(), and + against concat.

Trimming is the one worth noticing: Swift's lives in Foundation and takes a character set, which is more general and more to type. Roc's trim removes whitespace and that is all it does.

Swift's split returns [Substring], a view into the original string, which is efficient and occasionally surprising when the substring outlives its purpose. Roc's returns a list of real strings, and there is no Substring type to convert back from.

This is a place Swift is unambiguously better. Roc has no Character type, no grapheme awareness, and no way to ask how many user-perceived characters a string has — what it has is a byte count and operations that do not let you cut UTF-8 in half.

This is another close agreement. Swift's Array is a struct with copy-on-write, so assigning it copies only when someone writes — which is exactly what Roc's reference counting achieves, without a isKnownUniquelyReferenced check anyone has to write.

Roc has no shorthand argument names and no trailing-closure syntax, so every parameter is written out. That costs a few characters and removes the question of what $0 refers to three levels into a chain. There is also no lazy, so each step builds a real list.

Swift can pass an operator directly (reduce(0, +)) because operators are functions; Roc's are not first-class values, so the closure is written out. sum covers the common case in both.

Swift's trap is a deliberate choice: an out-of-range index is a programmer error, so the program stops rather than continuing with a wrong value. Roc treats it as an ordinary outcome instead, which is why ?? keeps the safe version about as short as the trapping one.

Swift already made the right default: sorted() returns a copy and only a var array gets sort(). The naming is the only thing to relearn — Roc's sort is Swift's sorted.

Swift's contains(where:) is overloaded with contains(_:) for equatable elements, and first is both a property and a method taking a predicate. Roc keeps each one a separate name, which is more words and fewer overload rules.

Note the argument order is the reverse of enumerated(), which yields the index first. Getting it backwards still type-checks whenever both happen to be numbers, so it is worth reading twice the first few times.

Swift reaches the same place by a different route — assigning a struct copies it — but only through a var, which makes the copy mutable for the rest of its life. The spread produces a new immutable value and leaves nothing mutable behind.

Swift gives a struct a memberwise initializer for free, which is close; Roc gives every record equality and Str.inspect for free as well, where Swift needs : Equatable and : CustomStringConvertible. The cost is that Roc's version is structural, so any record with the same fields fits.

insert returns a new dict rather than changing the old one, which is why the calls chain — a Swift dictionary is also a value type, so the difference is only that Roc has no mutating subscript to reach for. get returns a Try where Swift's subscript returns an Optional.

The difference is what a tuple can do. A Swift tuple cannot conform to a protocol, so it is not Equatable, Hashable or Codable — which is why so much Swift code turns a pair into a struct. A Roc tuple gets equality and Str.inspect like every other value, as the second line shows.

Swift already fixed fall-through, so that is not the difference. What is: every Roc arm must produce a value of the same type, so an arm that forgets to assign is a compile error rather than a definite-initialization error further down.

The first arm shows what makes them patterns rather than conditions: 0 is matched, not compared, and the compiler counts it toward exhaustiveness. A guarded arm never counts in either language, which is why the wildcard is still required.

Swift has tuple patterns and enum patterns but no array pattern, so the same logic switches on a count and then subscripts — and the compiler cannot connect the two, so numbers[0] in the count-1 case is bounds-checked at run time and could trap. In the Roc version the binding is the check.

Swift also has range patterns (case 1...3) and ~= for custom matching, neither of which Roc has. The alternatives matter more in Roc because they can be tags carrying payloads, and the compiler checks that the bound names agree across them.

One consequence is visible in the signatures. throws says a function can fail and, until typed throws arrived, said nothing about how — so the catch clause above is not checked for completeness and a second error type would fall through it silently. Try(I64, [BadScore(Str)]) names the failures, and a match that misses one does not compile.

The difference is which one is the default. In Swift, Result is a library type that competes with throws, so a codebase ends up converting between them at every boundary; in Roc there is no second channel to convert from.

Both languages mark every call that can exit early, which is the property that makes the control flow readable. Swift also has try?, which discards the error into an optional, and try!, which traps — Roc's equivalents are ?? with a default, and nothing at all.

Swift agrees with Roc here more than any other language on this site. precondition and fatalError are also uncatchable — do/catch does not see them — so the distinction between "a failure a caller should handle" and "a bug" is already one you draw.

There are no argument labels, no _ to suppress them, and no external-versus-internal parameter names — so a Roc call site shows only the values. That is less self-documenting than divide(17, by: 5) and it is also one fewer thing in every signature.

The Swift column prints 1005, not 15. Writing { [amount] number in … } captures the value instead — and that capture list also exists to write [weak self], which is the subject of the ARC section below.

Swift has default property values on a struct, so the two columns land in almost the same place — the difference is that Swift's defaults live on the type and Roc's live in a value you write once and spread from. What is genuinely lost is default arguments on the function itself.

Both languages monomorphize, so the generic really is specialized per type rather than erased. Swift can also compile a generic once and dispatch through a witness table when it has to cross a module boundary; Roc has no such fallback, which is simpler and means whole-program compilation.

Swift has the ternary for two branches and, since 5.9, if and switch expressions for a single-expression body. The Roc version cannot leave grade unassigned, because every branch must produce a value and an else is required when the result is used.

There is no range syntax — no 1...10, no stride — and no where clause on the loop, so a filtered iteration is a keep_if first. The same loop can also be written as a method, words.for_each!(|word| echo!(word)).

There are no compound assignment operators, so count += 1 is written out. There is no repeat ... while, no labeled break and no continue, so a loop that wants them is usually asking to be a fold.

There is no guard keyword, and with no optionals there is nothing for guard let to unwrap — the ? operator covers what guard let … else { return } is usually doing. What is lost is the compiler check that a guard's else branch really does leave the scope.

So the feature is missing and most of the need is missing with it. Swift also leans less on defer than C does, because ARC already releases objects at the end of scope — which is the same mechanism Roc uses, with the same consequence.

Swift has no such guarantee: the optimizer often performs the same transformation in release builds, and nothing in the language promises it, so the identical function can overflow the stack in a debug build. A guarantee and an optimization are different things to rely on.

Nothing declares that Celsius satisfies the clause: it has the method, so it fits. There is no protocol to define, no conformance to write, and no retroactive-conformance problem for a type you do not own — but also no protocol extension providing a default implementation, which is what Swift builds most of its standard library on.

The trade runs both ways. Swift's version is open — a new shape in another module joins the array without touching this code — while Roc's is closed and therefore exhaustively checked. Choose the tag union when the set of cases should be complete; Swift's any Shape when it is genuinely open-ended.

Method syntax works because the compiler resolves counter.describe() from the type it already knows. There is no mutating modifier to reach for, because nothing can mutate, and no extension to add a method later.

The consequence is the one async has: a pure function that gains a print has to change its signature, and so does every caller. Note that announce in the Swift column is not marked in any way despite printing — which is the gap the ! marker closes.

The reasoning is the platform model: a platform written in Rust may run an application's work across every core, and the application stays pure code that says what to compute rather than when. Next to Swift's structured concurrency and actor isolation, this is the largest single thing the page asks you to give up.

A failing expect prints every value that fed the expression, not just the expression that was false. Swift's assert is also removed in release builds by default, where a Roc expect has no such mode.

Two objects holding each other keep each other's count above zero forever, and no amount of scope exit will free them. Roc has no such case: nothing can be made to point back at a value that already exists, so counting alone is sufficient and there is no weak keyword, no [weak self] capture list, and no leak to find with Instruments.

The outcome is identical and the effort is not. A Swift library type gets copy-on-write only if its author writes isKnownUniquelyReferenced by hand; in Roc the compiler applies the optimization to every value in the program, because immutability makes it always safe.

A Swift global is lazily initialized on first access, with a swift_once check every time it is read, which is why globals are safe to use before main and why they cost slightly more than a constant. Roc has no such distinction — every top-level definition is a constant.

The fix is an annotation or a suffix: typed : List(I64), or 42.I64 on the literal. Swift has the same machinery with a friendlier default — ExpressibleByIntegerLiteral resolves an untyped literal to Int — so the habit of asking which numeric type you have transfers directly.

Annotating the binding, or writing Bool.True and Bool.False in full, pins it down. Note that ! is overloaded in Roc the way it is in Swift — negation as a prefix, and an effect marker as a name suffix — which reads oddly for about a day.

Use get(index), and first() or last() for the ends. Roc's last() returns a Try where Swift's last returns an Optional, so the two are the same shape and the force-unwrap has no counterpart.

This is the one place a Swift programmer must choose deliberately, because the default (:) is the structural one. Both versions are zero-cost at run time, and both reject a bare number at the call site.

There is also no Codable, no regular expressions, no date and time handling, and no grapheme-aware string model. Swift's standard library is unusually well designed; this comparison is not a fair one and it is a real one.

So the honest summary is narrow, and it is memory-shaped. Roc removes the retain cycle rather than giving you tools to break it, removes the optional rather than making it safe, drops the declaration a union needs, and puts every effect in the type system. It gives up async/await, actors, protocol extensions, grapheme-aware strings and the entire Apple ecosystem to do it.