C#.CodeCompared.To/Roc

The _args parameter is named with a leading underscore because the signature requires it and this program ignores it. Ok({}) is the return value, where {} is the empty record — Roc's void.

The difference is when the list is fixed. A C# assembly can reach for File.ReadAllText at any point and fail at run time if the host forbids it; a Roc application compiled against a platform with no file access cannot be made to name one.

Because the exit status is a return value, the compiler type-checks it, and there is no way to end the process from deep inside a library while skipping every cleanup step on the way out. Environment.Exit does exactly that: it skips the finally blocks on the stack (though ProcessExit handlers still run).

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

The trade is readability at a distance, and Roc convention answers it the way careful C# does — annotate the top-level functions. The difference is that a Roc annotation is checked against the inferred type rather than being the definition of it.

Point here is an alias for a shape, not a declaration of a new type. When you want C#'s nominal behavior — a type that only its own constructor can produce — := gives it to you; the Gotchas section has the worked example.

The Roc version needs no _ fallback, because its type says there are exactly two cases. The C# version needs a third arm for everything it was not designed for, and that arm is where a mistake lands silently — Describe(2.5m) compiles and returns "something else".

An alias buys readability and nothing else — neither language will stop you passing a UserId where any integer is wanted. When you want that check, C# reaches for a wrapper type and Roc for :=; both cost a construction step.

C# 8 added nullable reference types to describe a hole that was already in every reference slot, and the retrofit shows: the compiler warns rather than refusing, ! silences the warning, and the annotations are recorded in metadata but never enforced at run time, so a value arriving from a library compiled without them is neither checked nor trusted — it is simply unknown.

C# offers three ways to read a dictionary and they fail differently: the indexer throws KeyNotFoundException, TryGetValue returns a bool and an out parameter, and GetValueOrDefault hands back 0 for a missing int — indistinguishable from a stored zero.

C# has two: string? is a compile-time annotation on a reference, recorded in metadata but never enforced at run time, while int? is Nullable<int>, a genuine struct with a boolean field. They share a spelling and almost nothing else, which is why T? in a generic method needs the where T : struct or where T : class constraint to mean anything definite.

This row is the one place the C# and Roc columns print different text, and that is the lesson: a C# program using FirstOrDefault() on an int list cannot print the second sentence, because by the time it has a value it can no longer tell the two cases apart (asking Any() first, or passing a default such as FirstOrDefault(-1), is how C# code does). FirstOrDefault is where a great many silent zeroes come from.

C# makes you choose. A class gives reference semantics and the aliasing above; a struct gives value semantics but copies on every assignment and every argument pass, which is why the guidance is to keep them small and make them readonly. Roc removes the choice, and copy-on-write in the compiler removes the cost it would otherwise imply.

readonly in C# protects only the binding, so a readonly List<string> is a field you cannot reassign holding a collection anyone can empty. This is the same shape as const in JavaScript and val in Kotlin, and it is the gap ImmutableList<T> exists to close, one type at a time (ReadOnlyCollection<T> only narrows it: it is a read-only view over a list its owner can still change).

The C# property here is get-only and it still leaks: the getter returns the same List<int> the object holds. Returning scores.ToList() (a copy on every read) or AsReadOnly() (a read-only view) is the standard fix, and one the author has to remember to write.

C# 9's positional record generates the constructor, the properties, Equals, GetHashCode, ToString and a deconstructor. Roc generates none of those because it needs none: a record is structural, so equality and printing are defined on the shape rather than on a declaration.

The two are the same idea and they arrived from opposite directions: C# added with in version 9 for the case where copying is what you want, while Roc has no other kind of update, so the shorthand is the only way to change a field at all.

In C# it depends on the declaration: a record compares by value, a class by reference, and a struct by value through a reflection-based default that is slow enough that the guidance is to override it. Roc has one answer because it has no object identity for the other answer to be about.

C#'s positional deconstruction is by position, which means reordering the record's parameters (renaming does not matter) silently changes what every var (a, b) = … site binds. Roc matches on the field name, so the same edit is a compile error at each site instead.

Nothing is encapsulated here: any code holding this record can read balance directly. There is nothing to reach for either — := makes a type nominal, but a record literal with the right fields is still accepted where the nominal type is expected, with or without an annotation. Privacy in Roc is a convention, not a boundary.

C# wins this one. An extension method needs a static class, a this modifier and a using for the right namespace — and in exchange the call site reads the way the reader expects, and the method appears in completion on the type. |> recovers the chaining and not the discoverability.

The chain reads like the C# one, and the resemblance stops there. Every function in the block is an ordinary function whose first parameter happens to be an Account — there is no this to write, nothing is virtual, and nothing inherits. The block decides where a function is found, not how the call is dispatched; each of these resolves at compile time exactly as a free function would.

The two designs are open in opposite directions, which is the real trade. C# makes it easy to add a shape (write a class) and hard to add an operation (edit every class); the union makes it easy to add an operation (write a function) and hard to add a shape (edit every match). Neither is better; they fail in different places — and C# cannot make the union choice checked, since the compiler never treats a class hierarchy as closed.

The thing C# has that this does not is an open set: a fourth animal can arrive from another assembly at run time and the existing code will call its Speak. Roc trades that for exhaustiveness — nobody can add a case behind your back, and nobody can forget one either.

C# has no way to write that type. An enum is closed, an interface is open but requires every case to be a declared type implementing it, and neither lets a caller invent a case at the call site. Being able to choose per function is the part of Roc's tag system with no C# counterpart at all.

The shapes line up almost exactly, which is a fair measure of how much C# 8's switch expression took from this tradition. The difference is what happens when a case is missing, and the next row is about that.

C#'s check is a warning by default, and an enum makes it weaker still: (Color)99 is a legal value of the type, so no switch over an enum can ever be complete. Adding a fourth color to a Roc union breaks the build at every match that needs updating, which is the refactoring tool this comparison is really about.

That is the one place C# is more forgiving: its property pattern { X: 0 } simply ignores the rest, so the arms need not agree on which members they name. Otherwise this is among the closest correspondences on the page, because C# 8 and 9 took property, positional and relational patterns from exactly this tradition.

A guarded arm is invisible to the exhaustiveness check in both languages — the compiler cannot know whether n > 0 and its absence cover everything — so a guard needs the final _. C#'s relational patterns (> 0, < 0) are the shorter spelling for exactly this case, and are checked: arms that cover every integer need no _.

C# dropped checked exceptions on purpose, and the reasoning was sound — Java's version pushed people toward empty catch blocks and throws Exception. The cost is that no C# signature tells you what it throws, so the knowledge lives in documentation, and documentation is not checked against the code.

The two read alike here because the failing call is right there. They diverge when it is not: a C# try block can wrap a hundred lines and catch a FormatException thrown by any of them, while a Roc Try is tied to the one expression that produced it.

C# propagates by doing nothing, which is convenient and is also why a failure can travel a long way from where it happened before anyone notices. Roc propagates by writing one character, which is short enough not to be a burden and visible enough to read.

The payload is matched out by position, so the shortfall is a plain I64 by the time it is used. A C# exception carries a stack trace along with it, which Roc's tag does not; that is a genuine loss for debugging and a genuine saving in the cost of returning one.

Both languages keep a way out for the case that really is unrecoverable, and both make it deliberately unlike ordinary error handling so it is not reached for by habit. A crash in Roc is a statement that this state was supposed to be impossible.

The C# pattern exists for one reason: the collector manages memory and nothing else, so a socket or a file handle would sit open until a finalizer eventually ran. Deterministic release makes the whole apparatus — the interface, the statement, the analyzer that warns when you forget — unnecessary rather than automatic.

A finally block is insurance against an invisible exit. It is also its own hazard — a throw inside finally replaces the exception that was propagating (C# at least forbids return there). Removing invisible exits removes both the need and the hazard.

The names differ because Roc names the effect rather than the SQL clause — a C# programmer reading keep_if for the first time needs no gloss, which is more than Select can claim. string.Join converts each element for you; Str.join_with takes a list of strings, so the numbers are converted first.

LINQ's laziness is what makes Where(…).First() stop early on a million-row sequence, and it is also why the C# column prints 2, 3, 4 — the query was written before the 4 existed and ran after. Enumerating twice runs the query twice, and enumerating a query built from a database connection that has since closed throws at the foreach rather than where the query was built.

The one-argument Aggregate overload, which uses the first element as the seed, throws on an empty sequence. Roc has no such overload, so the seed is always written and the empty case is always the seed.

The two columns line up almost exactly here. Where they part is the general form underneath: C#'s IComparer returns an int whose sign carries the meaning, so one that returns it backwards compiles and sorts incorrectly, while Roc's three tags cannot be written the wrong way round and the compiler checks that all three are handled.

C# offers the pair, and choosing between them is choosing which failure mode you prefer: First throws InvalidOperationException with a message that names nothing about the query, and FirstOrDefault hands back a value that is indistinguishable from a real match on a list of integers.

This is the row where Roc asks for the most typing in exchange for the least drama: numbers[1] in C# is either the element or an ArgumentOutOfRangeException that ends the program, and the difference does not appear in the source. Str.inspect prints the Bool, which has no to_str of its own.

The obvious worry is that this copies on every append, and it usually does not: the compiler tracks how many references a list has, and when the old one is about to go out of scope it reuses the same memory. The Memory section shows that directly.

Without that suffix the values would be Dec, Roc's decimal type, and 30 would print as 30.0 — the single most common surprise on this page, and the Gotchas section returns to it.

C#'s named tuple elements have no counterpart, and that is deliberate rather than missing: a tuple whose parts deserve names is a record in Roc, where the names are part of the type and travel with the value instead of existing only as metadata for callers and vanishing from the run-time value the way C#'s do.

Both versions are checked once and work for every type. The difference is at run time: C# generics are reified, so List<int> is a distinct type the runtime knows about and can reflect over, while Roc erases the variable entirely after monomorphizing, which is why there is no typeof(T) to ask.

The two do the same job and differ in what they name. C#'s constraint is nominal: a type must declare that it implements IComparable<T>, which is why retrofitting one onto a type you do not own is impossible and why IComparer exists as the escape hatch. Roc's is structural: anything with an is_gt method qualifies without declaring anything — and equally, you cannot add is_gt to a type you did not write.

Because the alias is structural, { value: 42 } is already a Holder(I64) without being constructed as one — the annotation names the shape rather than selecting a class. C#'s Holder<int> is a distinct runtime type produced only by its constructor or a with copy. The name matters more than it looks: Roc's standard library already has a Box, and an alias that shadows a builtin is reported as one.

Forgetting the conversion is a compile error naming the type that arrived, which is the second most common thing to trip over on this page. The strictness has a point: C#'s interpolation converts whatever it is given, by ToString unless the type formats itself, and the default ToString on a class prints its type name.

The argument order is worth noting: Str.join_with(parts, " | ") has the list first and the separator second, the opposite of string.Join. It reads naturally in dot form as parts.join_with(" | ").

The two columns print different numbers and both are correct — é is one UTF-16 code unit and two UTF-8 bytes. The naming is the real difference: Length sounds like the number of characters and is not, which is how string-handling bugs survive review.

The reason C# needs StringBuilder is that string is immutable and += in a loop allocates on every pass. Roc's strings are immutable too, but the compiler sees that the accumulated string has one reference and appends into it, so the naive loop is already the efficient one.

C# has the full answer and also the trap it creates: ToUpper() uses the current culture, so under Turkish casing rules the dotted "i" uppercases to "İ", not "I", and breaks case-insensitive comparisons of identifiers. ToUpperInvariant exists entirely because of that. with_ascii_uppercased cannot fall into it: it converts ASCII letters and nothing else, which is exactly right for identifiers.

The naming is the improvement: int, long and byte have to be memorized, and long means something different in C. A literal too large for its annotated type is a compile error in both languages; the silent wrap C# gives you outside a checked block applies to arithmetic at run time.

C# decides from the operand types, so total / count silently truncates when both happen to be int — a bug that survives review because the source looks like the fractional division the author meant. Roc's / on two I64 values truncates the same way. What protects a Roc programmer more often is the default: a number literal with no annotation is a Dec, so 7 / 2 written with bare literals is 3.5.

The defaults are the opposite way round, and Roc's is the safer one: C#'s bare 0.1 is a double, so 0.1 + 0.2 prints 0.30000000000000004 unless the author remembered the m suffix. Roc makes you ask for the fast, lossy type by name.

The out parameter in the C# version is the shape of a language that had no way to return two things: TryParse predates tuples, nullable value types were awkward, and the pattern stuck. A Try return needs none of that machinery.

C# programmers know this rule as function coloring, usually as a complaint — async spreads up the call stack until it reaches Main. Roc makes the same trade deliberately and gets more for it: a signature without ! is a promise that the function reads nothing, writes nothing and prints nothing.

That makes the signature a guarantee rather than a description. In the C# column nothing about int Total(List<int>) rules out the logging line, which is why "is this method safe to call twice" is a question about the body rather than the signature.

The division is the interesting part. C# puts Task, the thread pool and the synchronization context in the base class library, so every program has them whether it wants them or not; Roc puts them in the platform, so a program compiled against a single-threaded one cannot name a thread at all.

The cost is real and worth naming: reference counting pays a little on every copy and cannot free a cycle. Roc gets away without a cycle collector because nothing in the language can construct one — a value can only refer to values that already existed when it was built.

This is the answer to the obvious objection that immutability must be slow. It holds precisely because the value is immutable: the compiler can prove nobody else is looking at that list, which is a proof it cannot make about a C# List<int> that any caller might have kept a reference to.

C# has spent releases mitigating this — generics to avoid boxing in collections, Span<T>, ref structs, generic math — and each one is an escape from a heap allocation that a universal base type made possible. The mitigations are good; not needing them is simpler.

A failing expect at the top level is silent on the platform this page runs on — it is collected by the test runner rather than evaluated here, so nothing about it reaches the output pane. Being in the language means no test project, no [Fact] and nothing to reference.

The difference from Debug.Assert is which builds it survives. C#'s is conditional on the DEBUG symbol by design, on the argument that a release build should be fast — which means the invariant you most want checked in production is the one that is not.

This is the first thing that surprises nearly everyone, and it surprises in a quiet way — the program is correct and the arithmetic is exact, but 6 prints as 6.0. Any example whose printed form matters should say which number type it means.

The error names a type, [Maybe, True, ..], that appears nowhere in the source, which is what makes this worth knowing before it happens. A Bool is printed with Str.inspect, which writes the tag's own name, True.

Both print 44. C#'s (byte) cast gets there silently: it compiles, it runs, and outside a checked block it keeps the low eight bits without a word. Roc does the same arithmetic only when the call site says wrap, and the try spelling puts the overflow in the type instead.

The asymmetry between building and matching is the part to remember: Tree.Node(…) to construct, bare Node(left, right) in the match. The C# column needs a base type and three declarations to say what one Roc line says.

The error for getting this wrong names self-reference rather than mutation, which reads oddly until you see why: total = total + number is a new definition of total whose body mentions total. The idiomatic version is usually fold, and the mutable form is there for when a loop genuinely reads better.