Java.CodeCompared.To/Roc

There is no class, because there are no classes — a top-level definition needs nothing wrapped around it. Ok({}) is the return value, where {} is the empty record, and _args has a leading underscore because the signature requires the parameter and this program ignores it.

The difference is when the list closes. Any Java class can call Files.readString or open a socket, and whether that is permitted is a question for the container it eventually runs in; a Roc application compiled against a platform with no file access has no name for one.

Because it is a return value rather than a global action, there is no way to end the process from four frames down. System.exit does exactly that: it runs shutdown hooks but not finally blocks, which is why calling it from library code is considered rude.

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

The sharp part is not that Java has null but that the type system cannot talk about it: String means "a string, or nothing", with no way to say which is meant. Every annotation scheme from @Nullable onward exists to add the distinction back, and none of them is enforced by the language.

Optional was the right idea implemented with the only tool available — a class — and a class reference can be null. That is why it is documented as a return type only, why putting one in a field draws criticism, and why Optional.ofNullable has to exist at all.

Java's Map.get returns null for a missing key, which is indistinguishable from a key stored with a null value — the reason containsKey exists as a separate question. On an int-valued map the returned Integer also unboxes on use, so the missing key becomes a NullPointerException at the arithmetic rather than at the lookup.

This is the clearest example of the page's theme. Java 21's exhaustive switch over a sealed interface is genuinely good, and null walks straight through it — the compiler accepts the switch as complete while the runtime can still hand it something none of the cases describe.

Java's defaults are what make a half-constructed object reachable — a field set in one constructor but not another, or an object published from a constructor before it finishes. The label above prints null, which is a value the author never wrote anywhere.

Java has two comparisons because it has two things to compare, and choosing the wrong one is the most common beginner bug in the language and a recurring expert one. There is no identity here to ask about, so there is no wrong choice to make.

Java's behavior here is correct and is also the reason a getter that returns a collection leaks it, why Collections.unmodifiableList exists, and why the advice is to copy on the way in and on the way out. None of that applies to a value nobody can change.

final protects only the binding, so a final List<String> is a field you cannot reassign holding a collection anyone can empty. It is the same shape as const in JavaScript and val in Kotlin, and it is what List.copyOf and the immutable collections exist to close, one type at a time.

The Java class above is written the way most are — private final field, a plain accessor — and it still leaks. The fix is List.copyOf(scores) in the constructor, which the author has to remember to write. The copy is immutable, so the accessor can return it as it is, and List.copyOf of a list that is already immutable returns that same list rather than copying it again.

Java's record generates the constructor, the accessors, equals, hashCode and toString. Roc generates none of them because it needs none: a record is structural, so equality and printing are defined on the shape rather than on a declaration.

Structural typing cuts both ways, and Java's nominal records give something real in exchange: a Coordinate cannot be passed where a Point is wanted, even though they are the same shape. Roc's answer when you want that distinction is :=, which the Gotchas section shows.

Java has no equivalent, which is why records with more than a few components collect hand-written withAge methods or a builder. Adding a component to the record then means visiting every place that rebuilt one — and since the constructor takes positional arguments, two components of the same type can be swapped without a compile error.

Both columns print 2, and how they got there is the point: Java changed the list the record was holding, and Roc built a new list and a new record around it. A Java record guarantees its own fields are final and nothing about what they point at, so record Team(String, List<String>) is an immutable holder for a mutable list. The documentation is explicit that a record is shallowly immutable; the word "shallowly" carries the whole warning.

This is the closest correspondence on the page: Java 17's sealed interfaces plus Java 21's pattern switch are this idea, arrived at from the object-oriented side. The cost is three declarations, three files in most codebases, and a permits clause that has to be kept in step. The two columns print 12.0 and 12 for the same number, which is worth noting once: Roc's F64 drops a trailing zero where Java's double keeps it.

The case is spelled Fine rather than Ok only to keep it clear of the Ok that Try uses. Nothing stops the reuse — tags are not registered anywhere — but a reader of this page would have to look twice.

Java has no way to write that type. An enum is closed, a sealed interface is closed by its permits clause, and an unsealed interface is open but requires every case to be a declared class implementing it. Choosing openness per function, at the use site, has no Java counterpart.

The two designs are open in opposite directions. Java makes it easy to add an animal (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 an animal (edit every match). Neither is better, and knowing which way your code grows is how you choose.

The asymmetry between building and matching is the part to remember: Tree.Node(…) to construct, bare Node(left, right) in the match. The Java column needs a sealed interface and two records to say what one line says here.

The shapes line up almost exactly, which is a fair measure of how much Java 14's switch expression took from this tradition — including the part that matters most, that arms do not fall through into one another.

Java's record pattern is positional, so it binds both components and then tests them in a when clause. Matching on the field name means the Roc version says what it wants directly, and it also means renaming or reordering the record's fields is a compile error at each site rather than a silent change in what gets bound.

A guarded arm is invisible to the exhaustiveness check in both languages — neither compiler can know whether n > 0 and its absence cover everything — so both still need a final catch-all. The Java column takes an Integer rather than an int because matching a pattern against a primitive is a preview feature, which is the boxing tax arriving in yet another place.

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

Java and Roc agree on the principle and almost nobody else does — C#, Kotlin, Scala and C++ all declined checked exceptions on purpose. The next four rows are about the specific things that went wrong in Java's version, because that is where the comparison is actually useful.

This is the single biggest difference from checked exceptions in practice. Java makes every layer restate a checked failure, so a change deep down edits a dozen signatures — and the pressure that creates is exactly why throws Exception and empty catch blocks became common enough to discredit the feature.

Java propagates by doing nothing, which is convenient, and the convenience is why a failure can travel a long way from where it happened before anyone handles it. The -1 above is the other common outcome: a sentinel chosen because returning something was easier than declaring the failure.

Because errors are a hierarchy in Java, catching is subtype matching: catch (Exception e) catches every Exception, including the NullPointerException that means your code is broken. Matching on a tag union catches exactly the cases the type lists, and adding a case breaks every match that now needs updating.

finally is insurance against an invisible exit, and it is its own hazard: a return inside one silently discards the exception that was propagating, and the compiler allows it. Removing invisible exits removes both the need and the hazard.

The bookends are the difference in daily use: a Java collection is not a stream, so every pipeline starts by converting and ends by collecting, and forgetting the terminal operation means nothing runs at all.

Laziness is what lets filter(…).findFirst() stop early on a huge source, and it is also why the Java column prints 3 rather than 2. A stream is single-use as well, so consuming one twice throws IllegalStateException rather than recomputing.

The mapToInt in the Java column is the boxing tax: Stream<Integer> has no sum, because summing boxed objects is not something the API wants to encourage, so there is a parallel family of primitive streams to drop into.

Java's findFirst returns an Optional, which is the right answer, and then Optional is a class whose reference can be null — so the improvement stops one level short of the guarantee. The tag union has no level to stop short of.

List.get in Java throws IndexOutOfBoundsException, and nothing in its signature says so, because unchecked exceptions are exempt from the throws discipline. That exemption is why "failure in the signature" describes only part of Java even where it applies. The last line differs only in spelling — Java prints true and Str.inspect prints the tag's own name, True.

The obvious worry is a copy on every append, and usually there is not one: the compiler tracks how many references a list has and reuses the memory when the old one is about to go out of scope. The Runtime 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, which the Gotchas section returns to.

Java's arrays are covariant — String[] is assignable to Object[] — which makes the type system unsound, so every array write carries a run-time check to catch it. Generics were deliberately made invariant to avoid repeating this, which is why List<String> is not a List<Object>.

The declaration site is the only cosmetic difference; the real one is at run time, and the next row is about that.

That sounds like erasure and is the opposite of its problem. Java erases so that generic code compiles to one class, which is why new T[] is impossible, why an unchecked cast is only a warning, and why List<String> and List<Integer> cannot be overloads. Roc compiles a specialized version per type instead, so nothing is lost and nothing is left to query.

Java's constraint is nominal: a type must declare implements Comparable<T>, which is why Comparator exists for types that do not and why the recursive <T extends Comparable<T>> is needed to say "comparable with itself". Roc names a method instead of a type, so the self-reference disappears — and so does retroactive implementation, since you cannot add is_gt to a type you did not write.

Because the alias is structural, { value: 42 } already is a Holder(I64) without being constructed as one. The name is not arbitrary: Roc's standard library has a Box, and an alias shadowing a builtin is reported as such.

Convention is to annotate top-level functions anyway, so a reader can see the shape without reading the body. The difference is that a Roc annotation is checked against the inferred type rather than being the definition of it.

Java has nothing like this, which is why the pattern is a record and why the wrapper survives into every signature, every call and every hot loop. Roc's := gives the Java behavior when the distinction is wanted — the alias is for when only the name is.

Java's wildcards exist entirely to recover flexibility that invariant generics removed, and the guidance for when to use which — produce with extends, consume with super — is a rule people memorize. No subtyping means no such rule.

Java has no tuple, so returning two things means declaring a type for the pair — which is better documentation and worse when the pair is incidental. The record above exists for one call and one line.

Java still has no interpolation, so the choice is + concatenation, formatted with a format string whose placeholders are checked only by a linter, or a StringBuilder. Roc's strictness is the opposite extreme, and it is the second most common thing to trip over here.

Both columns are correct and print different numbers — é is one UTF-16 code unit and two UTF-8 bytes. The naming is the real difference: length() sounds like a count of characters and is not, which is how string bugs survive review.

Java's String.split takes a regular expression, which is a genuine trap: splitting on a literal dot needs "\\.", and splitting on a user-supplied string needs Pattern.quote. The name gives no hint that a regex is involved.

Java needs StringBuilder because String is immutable and += in a loop allocates on every pass. Roc's strings are immutable too, and the compiler sees that the accumulated string has one reference and appends into it — so the naive version is already the efficient one.

Roc also has unsigned types such as U8. Java's byte, short, int and long are all signed, so a byte read from a stream arrives as a number from −128 to 127 and has to be masked with & 0xFF to be read as the 0–255 value it was.

Java's output here is true then false, and both are correct behavior: Integer.valueOf caches −128 to 127, so == on boxed integers is reference comparison that happens to work for small values. Code tested with small numbers and shipped with large ones is a real bug, and a famous one.

Java's wrapping is at least defined, which puts it ahead of C's signed overflow, and it is still a wrong answer that keeps running. Math.addExact exists and throws instead, which is the behavior Roc makes the default.

The defaults are opposite, and Roc's is the safer one: Java's bare 0.1 is a double, so 0.1 + 0.2 prints 0.30000000000000004, and the exact alternative is a class whose arithmetic is method calls. Roc makes you ask for the fast, lossy type by name.

NumberFormatException is unchecked, so nothing obliges the try block above — the version without it compiles, runs, and dies on the first piece of bad input. That exemption for unchecked exceptions is where most of Java's actual failures live.

That makes the signature a guarantee rather than a description. int total(int[]) in Java rules out nothing, which is why "is this method safe to call twice" is a question about the body rather than about the type.

Java went the other way on purpose. Virtual threads make blocking cheap so that ordinary synchronous code scales, and no function needs a marker at all. The two languages made opposite bets: Java bought back uncolored code at the cost of a signature saying nothing, and Roc kept the coloring and got a signature that means something.

This is the part of the argument that gets stronger the larger a program grows: synchronized, volatile, AtomicInteger, the happens-before relation and the whole Java memory model exist to make shared mutable state safe. Removing the sharing removes the subject.

The costs are real: a little arithmetic on every copy, and no way to free a reference cycle. Roc gets away without a cycle collector because nothing in the language can build one — a value can only refer to values that already existed when it was constructed, which is not true of any Java object graph.

This is the answer to the objection that immutability must cost a copy, and it holds because the value is immutable: the compiler can prove nobody else is looking. It is exactly the proof that cannot be made about a Java ArrayList whose reference any caller might have kept.

That matters for a command-line tool, a serverless function or anything invoked often and briefly — the case Java has spent years attacking with class-data sharing, AppCDS and native images. It matters much less for a server that starts once and runs for a month.

This is where Java's runtime earns its cost, and saying so is the fair version of this section. A generational collector turns allocation into a pointer bump and makes short-lived garbage nearly free, which beats reference counting on allocation-heavy work; and a JIT with real profile data can inline through a megamorphic call site in a way no ahead-of-time compiler can. A long-running server is precisely the shape that wins on both.

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.

Java is in the same position for the same reason: a helper you write for a type you do not own is Helpers.describe(value) forever, and reads inside-out when chained. Neither language lets you extend a type you did not declare, and |> is the thing Roc has that Java does not.

This is as close as Roc comes to a class, and the previous row understates it. What it still is not: withdraw takes the account as an ordinary first parameter, so there is no this; the block cannot be subclassed, implemented or extended; and every call is resolved at compile time, so none of the dispatch Java spends an interface on happens here. Roc gets its polymorphism from tag unions and from where constraints instead.

Java's effectively-final rule exists because a lambda captures by value and a mutable local would make the copy misleading. Every binding here is already immutable, so the rule has nothing to restrict and never needs explaining.

Comparator.comparingInt exists because the underlying interface is still "return an int whose sign means something", and it is a library making that safe for the common case. Roc's general form is three named tags rather than a sign, so a comparison cannot be written backwards: one that returns the wrong sign in Java compiles and sorts incorrectly, and a tag by the wrong name does not compile.

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 source set, no JUnit dependency and no @Test.

Java's assert is off by default — it needs -ea on the command line — which is why most codebases avoid it entirely and throw IllegalArgumentException instead. An invariant that is only checked when someone remembered a flag is not really checked.

This is the first thing that surprises nearly everyone, and it surprises quietly — 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, where Java prints the lowercase keyword.

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.

Leaving the annotation off entirely also works, since an inferred error type is open already. The failure mode is worth recognizing: the error message talks about a payload type rather than about the annotation, so the line it points at is the ? and not the signature that caused it.