Go.CodeCompared.To/Roc

The _args parameter is named with a leading underscore because it is required by the signature and unused — Go would refuse to compile an unused variable for the same reason the convention exists here. Ok({}) is the return value, where {} is the empty record.

The platform behind this page provides exactly one effect, echo!, which is why no example here opens a file or a socket. Swap the platform and the same application code targets a command-line tool, a web server, or a microcontroller with no runtime at all — which is where Go cannot follow.

Because the exit status is the function's return value, the compiler type-checks it. There is no os.Exit to call from the wrong place — and no deferred function silently skipped because os.Exit does not run them.

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

The Go column prints "" 0 false, which is a perfectly valid Config that nobody configured. That is the cost of the guarantee — "was this built by the constructor" is a question Go code asks constantly and cannot answer, and in Roc it cannot be asked.

The trade is readability at a distance: a Go signature always tells you the types, and a Roc one only does when someone wrote it. Convention in Roc is to annotate top-level functions for exactly that reason, and the compiler checks the annotation rather than trusting it.

Both columns print 44, and that is the point — Go arrived at it by removing the high bits of 300 and calling it a conversion, while the Roc column had to be written with a number that fits. The Go behavior is documented and it is still the kind of thing that reaches production, because nothing at the call site looks wrong.

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

Go's const is the nearest thing, and it works only for compile-time constants of basic types — there is no const struct and no const slice. In Roc that restriction disappears because everything has it. 🚨 Measured on the pinned build, a duplicate definition is a WARNING rather than an error — it compiles, and the name takes the new value from that point on. Single assignment is Roc's intent and the compiler says so loudly, but a pre-1.0 build has not finished enforcing it. Write as though it were an error, because it is meant to become one.

A var is local to its function and cannot escape, so there is no package-level mutable state and no equivalent of a global that two goroutines might reach at once.

The Go column shows the whole reason the decision exists: the same field, incremented twice, changes once. Roc removes the question rather than answering it — nothing can be modified through any reference, so passing a value is always safe and the compiler still avoids the copy whenever it can prove nobody else holds the original.

Naming a record's fields pulls them out by name, with the compiler checking that each one exists. Go has to name each field twice, once to read it and once to bind it, which is why struct-to-local unpacking is rare in Go code.

The Go signature says *string, which means "a string, or nothing, and the compiler will not remind you which". Forgetting the check is a nil dereference at run time; forgetting the Missing branch in Roc is a compile error naming it.

The Go column prints false: the function returned a nil *MyError, and err != nil at the call site is therefore true, so a program with no error takes the error path. Nothing in the Roc column can be nil, so there is nothing for a wrapper to hide.

The rules above are learnable and they are still rules — "can I write to this map" is a question about how the map was created, answered at run time. An empty Dict and an empty List in Roc behave exactly like non-empty ones.

The last Go line prints 0 for a key that is not there, which is also what it would print for a key stored as zero. ?? makes the same fallback explicit in Roc, and the reader of the code can see that a default was chosen. Both columns print the same two lines, which is the point: the difference this row demonstrates is in what the source obliges you to write, not in the answer.

Count what the Go column needs: an interface, two marker methods, a type switch, and a return 0 for a case that cannot happen but that the compiler demands. Add a third shape and the Go version still compiles and silently returns zero; the Roc version stops compiling until the new case is handled.

The second Go line is the point: Color(99) is a legal Color and the switch falls through to the "?" that had to be written for it. Roc's match needs no fallback, because there is no fourth value to fall back for.

Go's stand-in for a two-state value with no declaration is a string, and a string is a poor discriminant: "mornign" compares false and nothing complains. Roc knows the union is exactly [Morning, Afternoon], so a misspelling is a compile error and so is a missing branch.

Go's version of "or something else" is any, which gives up on the type entirely. The Roc signature keeps the closed part closed — the compiler still checks that Go and Stop are handled — while leaving the extension point open.

The two columns do the same work in twenty-five lines and six. The Go version also admits a state the Roc one does not: a Node with a nil Left is constructible, compiles, and panics at whatever depth it happens to sit.

What Roc adds is Dec, a fixed-point decimal type with no Go equivalent in the standard library. What it removes is int and uint, the platform-dependent sizes, so every integer in a Roc program has a width you can name.

Go's answer is math/big, which means a different type with methods instead of operators, and a decision at every arithmetic site. Here the difference between the two Roc lines is one annotation.

That decision is the trap: in Go, 17 / 5 and 17.0 / 5.0 are different operations spelled almost identically, and a change of variable type silently changes which one runs. Two operators cannot be confused that way.

The Go column prints the smallest int64, because Go defines signed overflow as wrapping. That is predictable and it is still a bug every time it happens. Underscores as digit separators work in both languages.

A format string is a second little language that the compiler checks separately — go vet catches a mismatched verb, and only because somebody wrote a checker for it. Interpolation puts the expression where it is used, so there is nothing to keep in step.

The two forms are the same function: "a".concat("b") is resolved at compile time to Str.concat("a", "b"). There is no strings.Builder because there is nothing to build into — but repeated concatenation costs the same as it does in Go, so joining a list is Str.join_with rather than a fold.

Method syntax here is sugar: "ab".repeat(3) is resolved at compile time to Str.repeat("ab", 3), so it is the strings.Repeat call with the receiver moved. Str.inspect turns a non-string value into something printable.

What is missing is the rest of the strings package and all of regexp — this build has no regular expressions at all, so anything more elaborate than a literal separator is a fold over the bytes.

The difference is what sits on top. Go adds a rune type and unicode/utf8 for character-level work; Roc has no Char type and no way to subscript a string at all, so there is no byte index to get wrong in the first place.

That removes the most surprising thing about slices, covered two rows down: because a Roc list has no backing array to share, no two lists can ever be views of the same memory.

The Go column prints [1 2 99 4 5] — appending to head replaced the third element of numbers, which nobody asked it to touch. The Roc column prints the original unchanged, because take_first produced a separate list and there is nothing to share.

The Go loop is not hard to read; it is hard to read quickly, because the intent is spread across a declaration, a range, a condition and an append. The chain says filter-then-double in the order it happens.

The starting value is not optional, so there is no empty-slice special case to get wrong. sum exists for this particular fold because it is so common.

Go's bounds check is real and its response is a panic, which is an exception in all but name — recovered with defer and recover, or not recovered at all. ?? supplies a default when that is what you want, which keeps the Roc version about as short as the subscript.

The last Roc line shows numbers unchanged after two sorts. sort.Ints always rearranges the slice it was given, which matters when that slice is a view of something else — see the aliasing row above.

The Go column shows what these cost written out, and where the comma-ok habit comes from — the "was there a match" flag has to be carried alongside the value because there is no way to return one-or-nothing. find_first returns a Try, which carries both in one value.

Note the argument order is the reverse of range, 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.

Go reaches the same place by a different route: a struct is a value, so assigning it copies. That works until the struct contains a slice or a map, at which point the copy shares them — a shallow-copy question Roc does not have, because nothing it could share is mutable.

The difference is nominal versus structural. Go would reject an identically-shaped struct of another name; Roc accepts any record with those fields. Equality and Str.inspect come free on every record, so there is no String() method to write.

insert returns a new dict rather than changing the old one, which is why the calls chain. Roc also preserves insertion order when iterating, where Go randomizes it deliberately — a decision made to stop people depending on an order that was never guaranteed.

The second Roc line shows what that buys: a list of pairs, with no struct declared for it. In Go the same thing needs a named type, or an anonymous struct written out at every mention.

Go's == works on structs of comparable fields and refuses to compile for maps, slices and functions, so comparing them means reflect.DeepEqual — reflection, unchecked at compile time, and slow. Roc needs no such escape hatch, because nothing has an identity separate from its contents.

Go already fixed the fall-through problem, so that is not the difference here. 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 zero value the reader has to notice.

The first arm shows the difference: 0 is a pattern, not a comparison, and the compiler counts it toward exhaustiveness. A guarded arm never counts, in either language, which is why the wildcard is still required.

The Go version switches on a length and then indexes, so the compiler cannot connect the two: numbers[0] in the case 1 arm is bounds-checked at run time like any other subscript. In the Roc version the binding is the check.

Go's compiler cannot do this even in principle, because Color is an integer type with four billion values. The nearest thing is exhaustive, a third-party linter you have to install, configure and remember to run — and it works by convention, not by type.

This is another place the two languages agree in substance. It matters more in Roc, where the alternatives can be tags carrying payloads rather than only constants.

The Go version has to invent a zero score to return alongside the error, and a caller that ignores err gets that zero silently. In Roc there is no second value to ignore: Ok and Err are different shapes, and the compiler will not let you read a score out of a failure.

This is the proposal Go has debated for a decade and repeatedly declined, most visibly as try in 2019. The argument against it is that hiding the return makes control flow less obvious; the counter is on screen here, where one character marks the exit and the reader can still see every one of them.

Go's error is one interface, so the signature says only "something can go wrong" and the caller has to know which sentinels to test for. The Roc signature lists them, and a match that misses one does not compile.

That is deliberate. recover turns an assertion failure into a catchable event, so a library can swallow a genuine invariant violation and carry on with whatever state caused it — which is how a panic in one request handler becomes a corrupted cache for everybody else.

Go already comes close — func literals are values and closures work the same way — so this is mostly a change of notation: | instead of parentheses, and the type on its own line above.

The Go column prints 1005, not 15 — the closure saw the assignment that happened after it was created. This is the same mechanism behind the loop-variable capture bug that Go 1.22 finally changed the semantics to fix.

The Go column is the functional-options pattern, which exists precisely because Go has no default arguments either — and it costs a type, a constructor per option, and a loop. The record is the same idea with the machinery removed.

Go reached the same place in 1.18 with more ceremony: square brackets, a constraint (any) that must be written even when there is none, and a set of rules about what can be inferred at the call site. Roc has had type variables since the beginning, and inference for them is not special-cased.

Go has no ternary either, deliberately, so the declaration-then-assign shape above is the idiomatic one. 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 index to discard, so the _ disappears. The same loop can also be written as a method, words.for_each!(|word| echo!(word)), which is the form that chains — and in pure code the equivalent is fold or map, which produce a value.

Go famously has one loop keyword doing four jobs; Roc splits them into for ... in and while. There is no labeled break and no continue, so a loop that wants either is usually asking to be a fold or a keep_if.

Writing return on that last line would also work; leaving it off is the convention, and it is the same one that makes if and match expressions.

So the feature is missing and the need is mostly missing with it. What is genuinely lost is defer as a general "run this on the way out" mechanism, including the recover idiom — and that is gone on purpose, as the crash row explains.

Go does not optimize tail calls, so the same function really does build a hundred thousand frames. It survives because goroutine stacks grow on demand, which is a different solution to the same problem and one that costs memory rather than refusing to.

Both are structural: neither Celsius declares that it satisfies anything, and both columns print 21.5°C. The difference is dispatch — Go's interface value carries a method table and is resolved at run time, while Roc resolves the call at compile time from the concrete type, so there is no boxing and no indirect call.

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

The receiver becomes an ordinary first parameter, which is what a Go receiver already is. There is no pointer-versus-value receiver decision, because there are no pointers, and no embedding — a Roc type cannot be extended by another.

Adding an echo! to describe would not compile: its signature would have to change, and so would every caller. Go's nearest equivalent is passing an io.Writer and hoping nobody reaches for fmt.Println instead — a convention rather than a rule.

A failing expect prints every value that fed the expression, not just the expression that was false. Go has no assertion at all, deliberately, which is why the column above is an if and a panic.

Go does this too — for const, and only for the basic types const supports. A package-level var with a function call in its initializer runs at startup instead, which is where init() ordering problems come from. In Roc there is no distinction, because every top-level definition is a constant.

The reasoning is the platform model: a platform written in Rust may well run a Roc application's work across every core, and the application stays pure code that says what to compute rather than when. That is coherent, and it is also a real limitation today, because the set of platforms that actually do it is small.

This is not a fair trade as it stands: Go gives you the hazard and the tools, Roc gives you neither. It does say what a platform-provided parallel map could safely do, though, which is the direction the design is pointed.

Nothing in Roc can be made to point back at a value that already exists, which is exactly the condition under which counting alone suffices — so the retain and release calls are inserted by the compiler and there is no collector, no write barrier, and no pause to tune. The cost is on screen: the Go column can build the cycle and the Roc column cannot.

That is why an immutable style costs less in Roc than copy-then-mutate costs in Go. Here both lists are printed, so both must exist and a copy really is made; drop the second echo! and the copy disappears.

The difference is what is inside. Go carries its runtime — a scheduler, a garbage collector and the standard library — which is why a hello-world binary is measured in megabytes. Roc carries whatever the platform is, which for a minimal platform can be almost nothing, and is how the same application code can target a microcontroller.

The fix is an annotation or a suffix: typed : List(I64), or 42.I64 on the literal. Go's untyped constants have a similar rule with a friendlier default — an untyped integer constant becomes int in context — so the instinct to ask which numeric type you have is already there.

Annotating the binding, or writing Bool.True and Bool.False in full, pins it down. It is the same inference rule that turns untyped numbers into Dec, seen from another angle.

Use get(index), and first() or last() for the ends. Once you are used to it, last() reads better than numbers[len(numbers)-1] and cannot be off by one.

Go's nominal type still accepts an untyped constant, as the last line shows, so the protection has a hole exactly where the literals are. UserId.{ value: 42 } has to be written out, which is the point.

There is also no regular-expression support, no JSON, no HTTP and no time package — which is a fair summary of the gap. Go's promise is that code written in 2012 still compiles; Roc has not made that promise yet and could not keep it if it did.

What Roc adds is worth studying now: sum types with exhaustiveness, no nil, no zero values, effects in the type system, and reference counting instead of a collector. What it lacks is everything around the language. Read it for the ideas, and keep writing the service in Go.