Rust.CodeCompared.To/Roc

The ! suffix on main! and echo! marks them as effectful functions — Roc tracks purity in the type system. main! receives the program arguments as a list and returns a Try: Ok({}) means success. There is no println! in the language itself; echo! is an effect provided by the platform hosting this program.

This is the deepest difference between the two languages. A Rust program links std and can open files, spawn threads, or hit the network from anywhere. A Roc program cannot perform any I/O on its own: it is embedded by a platform — a host written in another language (often Rust or Zig) — and the platform decides exactly which effects exist. This page runs your code on the minimal "echo" platform, whose only effect is echo!. The upside is that a platform can make hard guarantees: a Roc plugin literally cannot touch the filesystem unless its host offers that effect.

Both languages let the entry point return a result type instead of calling an exit function. Rust's fn main() -> Result<(), E> exits nonzero on Err; Roc's main! returns a Try, and returning Err(SomeTag) makes the program exit with code 1. {} is Roc's empty record — the equivalent of Rust's unit type ().

Roc has no let keyword and no mut — a plain name = value binding is immutable, period. Where Rust makes immutability the default with an opt-out, Roc makes it the rule with a separate, visually distinct opt-in for local mutation (next row).

Roc's var declares a reassignable local, and the $ sigil must appear on every use, so mutation is impossible to miss when reading code — like Rust's mut, but marked at each mention rather than only at the declaration. A var is local-only: there is no shared mutable state to send between threads, so Roc needs no borrow checker to police it.

Destructuring works the same way in both languages, with one Roc twist: the pattern must be exhaustive. You can destructure a tuple or a record directly, but you cannot write Ok(item) = list.first() as an assignment, because the Err case would be unhandled — use match for that.

Roc annotations live on their own line above the definition — name : Type — rather than inline after a colon. Roc uses full Hindley–Milner inference, so annotations are optional nearly everywhere, but any annotation you do write is checked, exactly like Rust. Note the capitalized builtin names: I64, Str, Bool, List(a) — generics use parentheses, not angle brackets.

Rust writes the type directly after the digits (42i64); Roc separates it with a dot (42.I64). The suffix mechanism is extensible in Roc: any type with a from_numeral method can be used as a literal suffix, so a custom Ratio type could accept 2.5.Ratio — checked and evaluated at compile time.

Rust defaults an unconstrained integer literal to i32. Roc defaults unconstrained number literals to Dec — a 128-bit fixed-point decimal — which is why the first list prints as [1.0, 2.0, 3.0]. This surprises everyone once. Annotate the binding (or use a literal suffix) whenever the printed representation matters.

The integer menus are identical: I8/U8 through I128/U128, matching Rust's i8–i128 sizes exactly (Roc just capitalizes them). Underscore digit separators work in both. Roc has no usize; list lengths and indices are U64 on every target.

Roc's flagship number type Dec is a 128-bit fixed-point decimal: 0.1 + 0.2 is exactly 0.3, no epsilon comparisons required. IEEE 754 floats (F32/F64) are still there when you want hardware speed — and give the same 0.30000000000000004 Rust prints. Rust has no decimal type in std; you would reach for the rust_decimal crate.

Roc spells integer division // (like Python) because plain / is reserved for exact division on Dec and floats. The remainder operator % matches Rust. Dividing by zero with // is an error in both worlds — Roc catches it at compile time when the operands are compile-time known.

Neither language converts numbers implicitly. Rust uses From/TryFrom for safe conversions and as for casts that can silently truncate; Roc's conversions are explicit methods like .to_i64() and .to_f64(), and there is no equivalent of the truncating as cast to reach for by accident.

Rust panics on overflow in debug builds and wraps in release builds unless you use the checked_*/wrapping_* families. Roc evaluates every top-level and compile-time-known expression during compilation, so I64.max + 1 is rejected before the program ever runs — the commented line produces "Integer addition overflowed!" as a compile error, not a runtime panic.

Roc interpolates with \u0024{...} inside any string literal — no separate format! macro needed. The catch for Rust programmers: interpolation only accepts Str values. There is no Display-style auto-conversion, so numbers need an explicit .to_str() call.

Roc has no + for strings (and no ++ in the current build) — concatenation is the concat method, callable in method style or as Str.concat. There is also no String-vs-&str split to think about: Str is the only string type, and reference counting makes sharing it free.

The everyday method names are almost identical: trim, repeat, starts_with, ends_with, contains, plus drop_prefix/drop_suffix where Rust has strip_prefix. Str.inspect is the debug-formatter — the closest thing to Rust's {:?} — used here because Bool has no .to_str() in the current build.

Rust's split returns a lazy iterator you must collect; Roc's split_on just returns the List(Str) directly. Joining goes through Str.join_with(list, separator) — note it lives on Str, so it is not available in method style on the list.

Both languages store strings as UTF-8 and write code-point escapes almost identically — Rust's \u{1F680} versus Roc's \u(1F680). Where Rust's len() quietly returns bytes, Roc names the method count_utf8_bytes() so nobody mistakes it for a character count; grapheme-aware operations live in a separate unicode package in both ecosystems.

Roc's List is the one sequential collection — contiguous in memory like Vec, not a linked list, despite the functional-language name. The literal syntax needs no macro. Str.inspect plays the role of {:?} for quick debugging output.

Roc's list transforms work directly on the list — no .iter() to enter iterator-land and no .collect() to leave it, and no *number dereferencing because there are no references. filter is named keep_if (with siblings drop_if and count_if). Thanks to opportunistic in-place mutation, this chain does not naively copy the list at each step.

The shape of fold is identical — initial accumulator, then a two-argument closure. Roc also ships fold_rev, fold_with_index, and fold_until (which can stop early by returning Break(value)), covering most of what Rust's richer iterator adapter zoo does.

Rust gives you both the panicking numbers[9] and the safe .get(); Roc only has the safe path — .get() returns a Try, and the panicking subscript simply does not exist. The ?? operator is Roc's unwrap_or: it substitutes a default when the expression is Err.

Rust's sort_by and reverse mutate the vector in place, which is why the binding must be mut. Roc's sort_with and rev return new lists — but when the original's reference count is 1, the "copy" is performed in place anyway, so the functional style costs nothing. The comparator returns Roc's LT/EQ/GT tags, a structural stand-in for std::cmp::Ordering.

Rust slices are borrows, and the borrow checker makes sure they never outlive the vector. Roc has no borrows, so take_first/drop_first/sublist conceptually produce new lists that share structure via reference counting — you can return them, store them, and never think about lifetimes.

The predicate helpers map one-to-one: any, all, and find_first (Rust's find), plus find_first_index for Rust's position. Notice what is absent on the Roc side: no iter(), and none of the *number/**number dereference noise that Rust's closure-by-reference iterators require.

Roc records are structural: { x: 1.5, y: 2.5 } just exists, no struct declaration required, and two records with the same fields are the same type. Field access is the familiar dot syntax. When you do want a named, distinct type, Roc offers nominal records — covered in the Methods section.

The spread-update syntax is nearly identical — Rust puts ..defaults last, Roc puts it first. Both produce a new value rather than mutating. Roc's version needs no #[derive(Debug)] to print: Str.inspect works on every value out of the box.

Tuples are the same idea with the same .0/.1 access syntax and the same destructuring. Like Rust, the index must be a literal so the compiler can verify it. One Roc note: a one-element "tuple" is just parentheses around a value — tuples start at two elements.

A type alias (single colon) gives a structural record a name for use in annotations, the way Rust programmers use struct for documentation as much as for typing. The alias is transparent — any record with those fields satisfies it. Note there is no &Employee: Roc functions receive values, and reference counting makes that as cheap as borrowing.

A nominal tag union (declared with :=) is Roc's enum: named, closed, and exhaustively matched. Construction is Color.Green, mirroring Color::Green. Inside a match the tags do not need qualification, and the compiler still verifies that every alternative is handled.

Payload-carrying variants translate directly, destructuring and all. At runtime a multi-payload tag compiles to the same layout as a tag holding a tuple — the same "discriminant plus fields" representation a Rust enum uses.

This is the feature with no Rust equivalent: structural tags spring into existence at the point of use. The if gives period the inferred type [Morning, Afternoon] — no declaration anywhere — and the match is still checked for exhaustiveness. It is Rust-enum safety with Python-level ceremony.

The .. in [Go, Stop, ..] makes the union open: the function accepts those tags plus any others, as long as a catch-all branch handles the rest. Rust approximates this socially with #[non_exhaustive]; Roc expresses it structurally in the type itself, and callers can pass tags the author never named.

In Rust, a recursive enum needs Box so the compiler can compute its size, and every construction site pays the Box::new tax. Roc's recursive tag unions are automatically heap-allocated and reference-counted behind the scenes — the type declaration and the construction both read like the textbook version.

Roc's match is Rust's match minus the commas between arms — same => arrows, same catch-all _, same compile error if a case is missing. Roc can also match directly on strings, which Rust allows too; both check exhaustiveness structurally.

Guards are character-for-character identical: pattern if condition =>. As in Rust, a guarded branch does not count toward exhaustiveness, so the final catch-all is still required.

Alternative patterns use the same | separator in both languages. This is one of several places where Roc's designers deliberately kept Rust's syntax, on the theory that Rust got it right.

Slice patterns translate almost symbol-for-symbol: Rust's rest @ .. becomes Roc's .. as rest. Roc matches directly on the List — no need to take a slice view of it first.

Try(ok, err) is Result<T, E> under a new name (it was called Result in older Roc). Fallible parsing lives on the number types — I64.from_str — rather than on the string. Note the error type: [BadScore(Str)] is an anonymous structural tag union, so you get a typed, pattern-matchable error without declaring an error enum.

Rust's beloved ? exists in Roc with the same meaning: unwrap the Ok or early-return the Err to the caller. Here main! simply passes show_first!'s Try along as its own result. Roc's designers cite ? as a direct Rust borrowing — one of Rust's ideas that survived the trip intact.

The ?? operator is unwrap_or as syntax: use the Ok payload, or fall back to the default on Err. For transforming instead of defaulting, Try carries the combinators you expect from Result: map_ok, map_err, ok_or, is_ok, and friends.

Roc has no null and, surprisingly, no built-in Option either. Where Rust reaches for Option, Roc either returns a Try (when the absence is an error) or an ad-hoc structural union like [Found(Str), Missing] — which needs no declaration and often carries better names than Some/None would.

Because Roc error tags are structural and unions are open, errors from different functions merge automatically: a function calling two fallible helpers infers the union of both error sets, with no From impls, no boxed dyn Error, and no thiserror derive. This is the part of Roc error handling Rust programmers tend to envy most.

Roc took Rust's closure syntax — |args| body — and made it the only function syntax in the language. There is no separate fn form: a top-level function is just a named value that happens to be a lambda, which is why the annotation sits above it like any other value's.

Rust closures force a decision — borrow or move? Fn, FnMut, or FnOnce? Roc closures just capture: values are immutable and reference-counted, so there is nothing to move, borrow, or classify. Returning a closure from a function needs no Box<dyn Fn> either.

Lowercase names in a Roc type annotation are type variables — a -> a is Rust's <T>(T) -> T without the declaration site. Like Rust, Roc monomorphizes: each concrete use compiles to specialized code with no runtime dispatch cost.

Roc's where clause constrains a type variable by the methods it must provide — where [a.to_str : a -> Str] reads like a structural, single-method trait bound. There is no trait to declare or implement: any type with a matching to_str method satisfies the constraint, and dispatch is resolved statically, exactly like Rust generics.

Rust does not guarantee tail-call optimization — deep recursion can overflow the stack, and the become keyword is still experimental. Roc guarantees that self-tail-calls compile to a loop, so the accumulator-passing style shown here is safe by design. Bonus: because sum_to is pure and its arguments are known, this example is actually computed at compile time — the running program just prints the answer.

Both languages make if an expression whose branches must agree in type, and both chain else if the same way. Roc's version is sugar for a match on Bool, and there is no truthiness — the condition must be an actual Bool, just as in Rust. Roc also drops the trailing semicolon question entirely: there are no semicolons.

Yes, the pure functional language has real while loops with break — mutation through var is local to the function, so it cannot leak or race, and the compiler is free to allow honest imperative iteration. Rust programmers can keep writing loops instead of translating everything into folds.

The langref specifies for word in words { } loops, but the pinned nightly build this page runs on rejects them (the iterator protocol is still being wired up) — so the idiomatic working form today is .for_each!(...), whose ! marks that its closure performs effects. Expect for to light up in a future nightly.

Roc has a genuine return statement for early exits, and the same convention as Rust for the happy path: the final expression of the function body is the return value, no keyword needed. Even the "guard clause returns early, main logic flows to the bottom" style translates unchanged.

This is Roc's counterpart to Rust's unsafe discipline, applied to I/O: an effectful function must carry a ! suffix and a => arrow in its type, and a pure function (->) cannot call an effectful one. You always know from the call site whether a function can touch the outside world. Rust's signatures are silent on the question.

Every top-level Roc value is evaluated at compile time — purity makes that always legal, so there is no const fn subset to learn. A top-level definition that would crash (say, an integer overflow) becomes a compile error instead of a runtime panic. It is const evaluation as the default instead of the exception.

An inline expect checks a condition mid-program, like assert!; if it fails, the program halts with a nonzero exit code. The same keyword doubles as Roc's unit-testing construct: top-level expect blocks are collected and run by roc test, filling the role of Rust's #[test] functions with less machinery.

Roc's crash is panic!: an unrecoverable abort for unreachable states, with the platform deciding what happens next — this row is display-only because the WASM host powering this page stops its instance on a crash (were it run, the Rust side would exit with the panic status 101). Roc culture matches Rust culture here: crash is for impossible states; expected failures should be Try values.

In Rust, let copy = original; would move the String and make original unusable — hence the .clone(). Roc has no move semantics at all: both names simply share the same reference-counted value, the compiler inserts the retain/release bookkeeping, and nothing is deep-copied. The entire ownership chapter of the Rust book has no Roc equivalent to learn.

The classic lifetime-annotation teaching example simply is not a problem in Roc: functions take and return values, reference counting keeps everything alive exactly as long as needed, and 'a has nothing to attach to. The cost is the refcount bookkeeping; the benefit is that this function signature never fights you.

Roc's memory model is roughly "what if Rc<T> were automatic, invisible, and optimized by the compiler." Heap values (strings, lists, recursive tags) are reference-counted; stack values (numbers, small records, tuples) are not. Because Roc statically rules out reference cycles, the classic Rc leak scenario cannot be expressed — no Weak pointers needed.

Roc's set looks like it copies the list, but the compiler uses Perceus reference counting to mutate in place whenever the value is unshared (reference count 1) — same machine code as the Rust version, without &mut. Rust guarantees exclusivity through the borrow checker; Roc discovers it through the reference count. (set returns a Try because the index might be out of bounds, so ?? supplies the fallback.)

A nominal type's trailing .{ } block holds its associated methods — Roc's impl. There is no self keyword: a method is any associated function whose first argument is the type, and value.method(args) dispatches to it statically. Method chaining works exactly as in Rust.

A nominal type (:=) is a distinct type the compiler will not silently mix with its backing representation — passing a bare record where a UserId is expected is a type error, exactly like Rust's tuple-struct newtype. Roc also allows directly value-backed newtypes (UserId := U64, constructed as UserId.(42)), but extracting their payload is not yet wired up in the pinned nightly build, so the record-backed form shown here is today's practical pattern.

Rust lets you choose between monomorphized generics and dyn trait objects. Roc removes the choice: all dispatch is static, resolved at compile time, with zero runtime overhead — there is no vtable mechanism in the language at all. If you need heterogeneous collections, you reach for tag unions instead of trait objects.

The number-one surprise: Roc's unconstrained numeric literals default to Dec, so the first line prints [1.0, 2.0, 3.0]. Rust's i32 default never changes how output looks; Roc's Dec default does. The habit to build: annotate any binding whose value you intend to display as an integer.

Rust's format! quietly calls Display; Roc's interpolation accepts only Str, so every number needs its .to_str(). It feels noisy for a day and then becomes automatic — and it means no accidental reliance on a type's formatting impl.

Because tags are structural, a bare False is just the tag False in an anonymous union — not necessarily a Bool — so operators like ! may fail to resolve without context. Annotate ready : Bool (or write Bool.False) and everything works. The same structural-tags superpower that removes enum boilerplate creates this one sharp edge.

Roc is pre-1.0 and this page pins a specific nightly compiler, so some familiar operations are missing or renamed: there is no Str.replace yet, string length is count_utf8_bytes(), list reversal is rev(), the pipe operator |> was removed in favor of method chains, and triple-quoted multiline strings are not implemented. Expect this table to improve as Roc approaches its first stable release.