Rust.CodeCompared.To/Java

Nothing in Java lives outside a class. System.out is a static field holding a PrintStream, and println is an ordinary method call on it — where println! is a macro that the Rust compiler expands and type-checks at the call site. Java has no macros at all, which is why the rest of this page reaches for reflection and annotations where Rust would reach for derive.

Java's args contains only what the user typed, so args.length is already the user-argument count and args[0] is the first real argument rather than the executable. Both programs print zero user arguments here because neither runner passes any.

The habit to unlearn is that a package name is free-form: in Java the package declaration must match the directory path, so package com.example.greeter; only compiles from com/example/greeter/. Dependencies come from Maven Central rather than crates.io, and are identified by a group and artifact pair instead of a single name. Neither column runs — these are build files, not programs.

The real difference is when the check happens. Passing an int to %s and forgetting an argument are both run-time IllegalFormatExceptions in Java, while println! is a macro that rejects the same mistakes before the program exists. Note %n rather than \n — it emits the platform line separator, which is what println uses too.

Because the default runs the other way, final is used far less consistently than mut is — a great deal of Java code never writes it at all. The deeper difference is that final only freezes the binding: a final List<String> can still have elements added to it, whereas a Rust binding without mut also denies you &mut to what it holds. Java has no keyword for deep immutability.

Rust infers a local's type from how it is later used, so let mut best; followed by an assignment is fine. Java's var is strictly initializer-driven: it needs a value on the same line, cannot appear on a field, a parameter or a return type, and cannot be null. That makes it a readability tool rather than the inference engine let is.

Rust has one i32 and you say Box when you want it on the heap. Java has int and Integer, and the conversion between them is invisible — which is why an innocent List<Integer> allocates an object per element. The consequences run through the whole page: generics cannot take a primitive, Integer can be null where int cannot, and == on two Integers compares references.

A Java local cannot be redeclared in the same scope, and it cannot be redeclared in a nested scope either while the outer one is still visible. The only shadowing Java does have is between a field and a local or parameter of the same name, which is why constructors are full of this.name = name; — and that is a source of bugs rather than a tool.

Rust's const is substituted into each use site and static names a single memory location; the distinction matters because a static mut is unsound to touch without unsafe. Java's static final is one slot per class, initialized when the class loads, and a mutable static field is ordinary code that any thread may write — the compiler will not stop you. Screaming snake case is the convention in both languages.

Rust makes you choose a policy — wrapping_, checked_, saturating_ or overflowing_ — precisely because silent wraparound is a decision rather than a default. Java's decision was made for you in 1995 and cannot change. Math.addExact and its siblings are the opt-in, and there is no saturating family at all: widening to long first is the usual workaround.

The consequence for a Rust programmer is that "cannot be negative" stops being a fact the type system knows. A length is an int, a byte read from a stream is a signed byte, and forgetting Byte.toUnsignedInt on binary data is one of Java's classic bugs. Integer.divideUnsigned, remainderUnsigned, compareUnsigned and toUnsignedString are the whole toolkit.

The half Java does implicitly is the safe half, so this is less dangerous than it looks — but int to float and long to double are also implicit and both lose precision, which is the one place the rule leaks. Rust's TryFrom returns a Result; Java's nearest equivalent is a scattering of ...Exact methods that throw, and there is nothing at all for "narrow this int to a byte if it fits".

BigInteger is arbitrary precision rather than merely wider, so it never overflows — but there is no operator overloading in Java, so arithmetic turns into add, multiply and mod chains, and every intermediate result is a new heap object. This is the same trade Rust makes when reaching past u128, except Rust's ceiling is twice as high before you get there.

The &str versus String decision that shapes every Rust API signature simply does not arise: a Java method takes String and that is the end of it. What you lose is the guarantee a &str gave you — that no copy was made. Java string literals are interned into a shared pool, so identical literals really are one object, but any string built at run time is a fresh allocation.

This is the single most misleading similarity between the two languages. Rust's char is a Unicode scalar value and always the whole character; Java's char is half of one whenever the code point is above U+FFFF. length() is therefore neither a byte count nor a character count, and code that iterates with charAt silently corrupts emoji. Use codePoints() when you mean characters — it is the closest thing Java has to chars().

Java strings are immutable in a way Rust's are not: String has no mutating methods at all, so text += word in a loop allocates a whole new string each pass. StringBuilder is the mutable counterpart, and calling toString() at the end copies once. Rust's String is already the growable buffer, which is why push_str exists on it directly.

The stripping rule is worth learning before it surprises you: Java removes the longest common whitespace prefix of all lines including the closing delimiter line, so moving the closing """ changes the string's contents. Rust does no stripping at all, which is why a multi-line literal in indented code carries the indentation with it. Escapes still apply inside a Java text block, so a Windows path still needs doubled backslashes.

Rust panics on a non-boundary index: &text[0..2] here would abort with a clear message about a character boundary. Java's substring will happily hand back a lone surrogate, which prints as a replacement character and compares equal to nothing you expect. That silence is the trap — an out-of-range index throws StringIndexOutOfBoundsException, but a mid-character one does not.

Two traps hide in the resemblance. Java's split takes a regular expression, not a literal — splitting on "." matches every character — while Rust's split takes a pattern that is literal unless you say otherwise. And indexOf returns -1 for "not found" where find returns Option<usize>, which is the null-versus-Option story in miniature. Prefer strip() over the older trim(): only strip knows the full Unicode definition of whitespace.

Everything the borrow checker was buying you goes away here. There is no move, so the old name stays valid; there is no exclusive &mut, so any number of names can write at once; and there is no compile error waiting when two parts of a program mutate the same list. What you get back is that a cyclic or shared data structure needs no Rc, no RefCell and no lifetime annotation — you just hold the reference.

You can delete the whole of lifetime elision from your working memory here; there is no 'a, no 'static, no dangling reference and no "does not live long enough". The bill arrives in two other forms. Objects are freed at a time nobody controls, so Drop-style cleanup is not available; and the Option<&String> that made "no match" a distinct case has become null, which the compiler does not force you to check.

Writing first == second where you meant equals is the mistake every Rust programmer makes in their first week, and it is worst on strings: two identical literals are interned to one object so == appears to work, until one of them is built at run time and it silently stops. The other half of the contract is that hashCode must agree with equals — override one without the other and your object gets lost inside a HashSet. Rust's derive makes them consistent by construction; record is Java's version of that guarantee.

Every Java assignment behaves like Copy in that it is cheap and implicit, and like nothing at all in that no data is duplicated. The deep clone Rust's #[derive(Clone)] generates has no Java equivalent — Object.clone() is shallow, awkward and widely considered a design mistake, so real code writes a copy constructor by hand. The practical answer is to make types immutable, which is what record encourages, so that sharing a reference is as safe as copying.

Java's collections keep a modification counter and the iterator compares it on each step, which is what raises ConcurrentModificationException. The name is misleading: no second thread is involved. It is also explicitly best-effort — the docs say so — so the same bug can instead produce a silently wrong result, and it does not fire at all for a modification made through a different thread. This is exactly the class of bug &mut exclusivity was designed to make unrepresentable.

The difference that matters is where the obligation sits. impl Drop is written once on the type and every value of that type is cleaned up, no matter how it is used; AutoCloseable only runs if each caller remembers try-with-resources, and a resource stored in a field is nobody's responsibility. That is why "leaked file handle" is a live category of Java bug and not a Rust one — and why RAII, which Rust inherited from C++, has no real counterpart here.

Rust has one growable array type and free functions on slices; Java has a family of them behind a shared interface, which is why the declaration and the constructor name different types. The other difference is the missing-element policy: get returns Option in Rust and throws in Java, so there is no "checked index" method to reach for — you check size() first or you catch.

This is a genuine hole, kept for compatibility with Java 1.0, which had no generics and needed some way to write a method over any array. Rust has no subtyping between concrete types, so the question never arises; Java's own generics later got it right — List<String> is not a List<Object> — which is why arrays and generics behave differently and mix badly. Note the array's length is names.length, a field with no parentheses, unlike every collection's size().

Rust's entry hands you a handle you can branch on and finish however you like, so or_insert, or_insert_with and and_modify are just methods on it. Java has no such handle: merge, compute, computeIfAbsent, computeIfPresent and putIfAbsent are five separate entry points covering the common cases. A TreeMap is used here only to make the printed order deterministic — HashMap iteration order is unspecified in both languages.

Because List.of returns the same List interface as ArrayList, a method receiving a List cannot tell whether it is allowed to modify it — the type carries no such information, and the answer arrives as an exception at run time. There is no read-only list type to declare, which is the price of retrofitting immutability onto an interface designed in 1998. Rust puts the same fact in the signature: &Vec<T> and &mut Vec<T> are different types.

Both sorts are stable. The interesting divergence is the key type: Rust's closure has to hand back an owned value, which is why the name is cloned here — sort_by with a two-argument comparator is the allocation-free alternative. Java's comparingInt avoids boxing the age, and thenComparing reads in the order you would say it aloud. Note List.of produces an immutable list, so it is copied into an ArrayList before sorting.

Before this, getting the last element of a List meant list.get(list.size() - 1), and the same operation had a different name on every collection type. reversed() is a view, not a copy, so it is closer to iter().rev() than to into_iter().rev().collect() — writing through it writes through to the original list.

The workaround Java reaches for first — declare the variable, then assign in each branch — is still checked for definite assignment, so forgetting a branch is a compile error rather than a null. The conditional operator is the real expression form, and it is the reason so much Java code stacks ? : chains where Rust would use if. Java's switch expression, further down this page, is where the language did finally adopt the idea.

The enhanced for loop — for (String letter : letters) — is the direct counterpart of for letter in &letters, and it is what you should reach for whenever the index is not needed. When it is needed there is no enumerate, so counting by hand is idiomatic rather than a smell. IntStream.range covers 0..n and rangeClosed covers 0..=n, but neither is usable as a value the way a Rust range is.

The syntax barely differs: Rust marks the label with a leading apostrophe and repeats it after break, Java writes a bare identifier and a colon. Where they part company is break value — a Rust loop is an expression that can hand a value back, and no Java loop can. The label itself is also more general in Java, since it may be attached to any statement, including a bare block you can jump out of.

The arrow form fixed the two oldest complaints about switch: cases no longer fall through, so the break that everyone forgot is gone, and the whole construct produces a value. It is only a partial match — the labels here are constants, not patterns, and it does not destructure. The next section is where that gap closes. When an arm needs several statements, wrap it in a block and end with yield, which is the counterpart of a Rust block's trailing expression.

You could write Integer job; while ((job = pending.pollFirst()) != null), and older Java code does, but assignment-inside-a-condition is exactly the pattern while let exists to replace — and here it would also unbox a possibly-null Integer. Checking isEmpty() first is the readable version and the one to write. Note ArrayDeque, not Stack: the older class is synchronized and effectively deprecated.

The mapping is clean once you see it: a Rust associated function without self is a Java static method, a method taking &self is an instance method, and a free function has to be adopted by whichever class it fits. The receiver is spelled self and declared in Rust, and is the implicit this in Java — which is why you can write reading instead of this.reading inside a method. There is no self versus &self versus &mut self distinction, because there is no ownership to express.

Overload resolution happens at compile time against the declared types, not the run-time ones, which is why it interacts badly with autoboxing and null: area(null) here would be ambiguous if a second single-object overload existed. Rust's answer to the same need is either distinct names, as above, or a generic function with a trait bound — which is a genuinely different mechanism, since it resolves one implementation per concrete type rather than choosing between hand-written candidates. Neither language has default parameter values.

Rust names three capture modes because ownership makes them observably different; Java has one, so mutating captured state means capturing a mutable object instead of a mutable variable — an AtomicInteger, a one-element array, or a field. The restriction exists because a Java lambda may outlive the stack frame it was created in, and copying the value is the only way to keep that sound without a borrow checker. A lambda body also cannot return from the enclosing method the way a Rust closure cannot.

The practical friction is that the method name changes with the interface: apply, test, get, accept, run — where Rust just calls the value. Because generics cannot take primitives, the java.util.function package also carries a primitive-specialized copy of nearly everything (IntUnaryOperator, ToIntFunction, IntPredicate), which is the boxing tax showing up in the API surface. What Java gains is that any interface you write with one abstract method accepts a lambda, with no Fn equivalent to implement.

Java recognizes four shapes — Type::staticMethod, instance::method, Type::instanceMethod (the argument is the receiver) and Type::new. Rust has only the first and last, because a method reference that turns an argument into a receiver is just str::len taking &self as its first parameter, which is already how Rust methods work. The compiler figures out which shape applies from the target functional interface, so the same text can mean different things in different contexts.

This is a small ergonomic win for Java, and it is what makes String.format, List.of and printf read the way they do. The costs are that only the final parameter may be variadic, that the array is allocated on every call, and that varargs plus overloading plus autoboxing produce genuinely confusing resolution — total(null) is ambiguous in a way no Rust call can be. Rust's answer, a slice parameter, costs one pair of brackets at each call site and nothing at run time.

The mechanical differences are small — data and methods live in one block rather than two, and self becomes an implicit this. The real one is that scale needs no &mut: any method may mutate the object, so nothing in a Java signature tells a caller whether it will. Rust's three receiver forms are load-bearing type information; Java simply does not carry it. Fields are made private and reached through methods because Java, unlike Rust, cannot later replace a public field with a computed one without breaking callers.

This is the construct that will feel most familiar, and it is worth defaulting to. The differences are worth knowing: the accessors are label() rather than a bare field, so a record's shape is methods rather than data; there is no derived Clone, because an immutable object never needs one; and there is no Default, PartialOrd or Copy to derive. A record is also implicitly final and cannot extend anything, which is what makes it safe to compare by value.

Note the last line: the variable is declared Animal but holds a Dog, and the Dog version runs. Every Java instance method is virtual by default, which is dynamic dispatch you did not ask for — the opposite of Rust, where you write dyn to get it. The trade is real: a subclass can depend on and break its parent's internals in ways a trait implementation never can, which is why "prefer composition over inheritance" is standing Java advice and why final on a class is worth writing.

Rust has no constructors, so the "make one or explain why not" function is unremarkable: it returns Result like anything else. Java's equivalent has to throw, and the caller has no signature-level warning that it might. That the check can sit above super() at all is new in Java 25 — before it, a constructor had to call its parent first, so an argument could only be validated inside a static helper passed as an argument to super(). The usual escape hatch remains a static factory method, which can return a subtype, a cached instance, or an Optional.

Because toString is inherited from Object, forgetting to override it produces something like Temperature@6d06d69c rather than a compile error — the counterpart of a missing Display is silence instead of a diagnostic. Anything concatenated with a string calls it implicitly, including inside a logger or a debugger. A record generates a reasonable toString for free, which makes it the closest thing to #[derive(Debug)].

Rust's default is private-to-the-module and every level is spelled out — pub, pub(crate), pub(super). Java's omitted keyword meaning "package-visible" catches people out, because it looks like no decision was made. protected has no Rust analog at all: it means visible to subclasses and to the package, which only makes sense once inheritance exists. Above all of this sits the module system, whose exports directive is the nearest thing to pub(crate) at library scale.

Two differences are structural rather than cosmetic. The conformance is declared on the class, in its header, rather than in a separate block — so a class must know at the moment it is written which interfaces it satisfies. And there is no dyn to write, because an interface-typed variable is always dynamically dispatched; Java has no static-dispatch form of this at all. A class may implement any number of interfaces, so multiple traits carry over unchanged.

Traits had default methods from the start; Java retrofitted them so that Iterable could gain forEach without breaking every class that already implemented it. The one thing Java cannot do is hold state — an interface has no instance fields, so a default method may only call other interface methods. Rust's restriction is the same in practice. Where an inherited default collides between two interfaces, Java makes the class disambiguate explicitly, which is its answer to the diamond problem.

This is the single largest expressive gap in the direction you are travelling. Rust's coherence rule lets you implement your own trait for any type, which is why extension-style APIs are everywhere; Java's answer is a wrapper class, and the wrapper is a different type, so it does not flow through code expecting the original. The nearest thing to a blanket impl is a static helper method taking the type as a parameter, which is how Collections, Objects and Arrays came to exist at all.

compareTo returns a negative number, zero or a positive one — the C convention — where cmp returns an Ordering enum with three named variants. Rust also splits PartialOrd from Ord so that floating-point types, which have no total order because of NaN, can say so in the type system; Java has one interface and Double implements it by declaring NaN to be larger than everything, which is a decision rather than a fact. Both languages warn that an order inconsistent with equality breaks sorted collections; only Rust's derive makes them consistent automatically.

Every Java call through an interface or an overridable method is a virtual call, and a generic type parameter changes nothing — it is erased to its bound, so drawGeneric and drawInterface compile to the same bytecode. What rescues the performance is the JIT: after seeing one implementation at a call site it will speculatively inline and de-virtualize, achieving at run time what Rust settles at compile time. The trade is a warm-up cost and a de-optimization whenever a second implementation shows up.

Java's enum is genuinely useful — the constants are objects, so they may have fields, methods and even per-constant bodies, and they come with values(), ordinal() and valueOf for free. But every constant of a given enum has the same type, so the moment two states need different data, an enum is the wrong tool. The next row is where Java's real sum type lives.

Everything you rely on carries over: the switch is checked for exhaustiveness, so adding a third shape without handling it is a compile error, and the default arm that would have hidden that mistake is unnecessary. What differs is the shape of the declaration — one type per variant rather than one type with variants — so Circle is a real type you can name in a signature, which Rust's Shape::Circle is not. Sealed types arrived in Java 17 and pattern-matching switch in Java 21; before that, this was written with a visitor or a chain of instanceof.

The parallel is close enough to be worth leaning on, and the gaps are real but narrow. Java has no | for alternative patterns that bind variables, no .. for "and the rest", and no range patterns; a variable pattern binds by position rather than by field name, so you cannot write Move(y) and skip x. Nesting works — case Write(String text) could be case Outer(Write(String text)) — and that is where record patterns earn their place.

A guarded arm never counts towards exhaustiveness in either language — the compiler cannot prove the condition is always true — which is why a final unguarded arm is still required here. Rust's wildcard is _ and Java's is default, and Java also accepts a bare _ as an unnamed pattern variable when the binding is not used.

The negated form is Java's let-else, and it works through flow scoping: the compiler tracks where the pattern must have matched, so the binding is visible after an early return but not on the failing path. Rust's version is explicit in the syntax rather than inferred, and it enforces that the else branch diverges. Note the Java example types the variable as Object — instanceof against a sealed hierarchy is the everyday use, but any reference type works.

A bound is written extends in both cases, even when the bound is an interface, and several are joined with & rather than +. There is no where clause. The deeper difference is that the bound is the only thing the method body knows: item.compareTo is available because Comparable declares it, and nothing else is — which is exactly how a trait bound behaves. Note that > becomes compareTo(...) > 0, because Java has no operator overloading.

This is the deepest structural difference in the whole language pair, and it costs you several things at once. There is no T::default() or T::new(), because T does not exist at run time; new T[10] is a compile error; value instanceof List<String> cannot be written; and two overloads differing only in type argument have the same erased signature and will not compile. The compensation is that there is no code bloat and no compile-time monomorphization cost — one ArrayList serves every element type.

The consequences are everywhere once you look. A List<Integer> of a million elements is a million heap objects plus a million pointers, where a Vec<i32> is four megabytes of contiguous memory; caching behavior differs accordingly. This is why IntStream, LongStream, DoubleStream, IntUnaryOperator and dozens of similar types exist — hand-written specializations for the three primitive types anybody cared about. Project Valhalla is the long-running effort to fix this properly, and it has not shipped.

The mnemonic is PECS: Producer extends, Consumer super. A List<? extends Number> can be read from but not added to, because nobody knows which subtype it really holds; a List<? super Integer> can be added to but reads back as Object. Rust has variance too, but it applies to lifetimes and to built-in types rather than being something you write, and the equivalent flexibility comes from trait bounds instead. Wildcards are the price of subtyping — with no subtyping there is nothing to vary.

That single declaration is the ergonomic win; the loss is that a method cannot add a bound the class does not have, so impl<T: Display> Stack<T> — extra methods available only for some element types — has no equivalent. Every method exists for every T. The diamond <> on the right-hand side is inference in the one place Java bothers with it, and it is why new ArrayList<>() reads the way it does.

This is the safety property you will miss most. There is one consolation: since Java 14, the NullPointerException message names the exact expression that was null — "Cannot invoke String.length() because the return value of findUser is null" — which turns the site's worst error message into one of its best. Note also that primitives cannot be null, so unboxing an Integer that happens to be null throws in a place with no visible method call at all.

The reason for that narrow guidance is that Optional cannot replace null — it sits on top of it. An Optional reference can itself be null, so Optional<String> has three states where Option<String> has two, and every wrapper is a heap allocation. It also has no pattern matching: orElse, orElseGet, ifPresentOrElse and map are the whole vocabulary, and get() is the unwrap() you should not reach for.

Optional.ofNullable is the bridge from the null world to the Optional world, and map here does the work of and_then — because map on an empty Optional short-circuits, and the mapper returning null also yields empty. When the mapper itself returns an Optional, use flatMap, which is the direct counterpart of and_then. The alternative every codebase also contains is a stack of nested if statements, and it is not wrong — just longer.

The consequence for a Rust programmer is that the return type stops telling you whether a call can fail. Integer.parseInt returns int, full stop, and only the documentation says otherwise. In exchange the happy path is uncluttered: there is no Ok(...) to wrap, no ? to remember, and a chain of ten calls needs one try rather than ten propagations. Both mechanisms unwind — a Rust panic! unwinds the same way — but only Java's is the ordinary route for expected failures.

Checked exceptions are the closest Java gets to putting failure in the type, and they are the one error-handling idea here with no Rust counterpart at all. They are also controversial: because throws propagates up through every intermediate signature, a deep call stack ends up either declaring the whole world or wrapping everything in RuntimeException to escape. They interact badly with lambdas as well — none of the functional interfaces in java.util.function declare throws, so a checked exception cannot escape a stream operation. The cause chain shown here is Java's answer to map_err: the original failure is retained rather than replaced.

This is where exceptions genuinely read better, and it is worth conceding. What it costs is locality: every call in that method is a possible exit point and none of them is marked, so "where can this return from" is no longer answerable by reading the body. Rust's ? marks each one and, through the From conversion it performs, forces you to decide how a foreign error type becomes yours — a decision Java makes implicitly by letting the original type fly straight through.

The shapes are dual: Rust matches on a value of one type, Java catches on one of several types. That gives Java something Rust lacks — a caller may catch MissingField specifically and let everything else pass — and costs it exhaustiveness, since no compiler checks that every subclass is handled. Making the base sealed and catching with a pattern switch recovers some of that. Note the message lives in the exception rather than in a Display implementation, because Throwable already carries one.

Rust puts a wall between the two: catch_unwind is unidiomatic, it does not work with panic = "abort", and the value it hands back is a Box<dyn Any> you cannot usefully inspect. Java uses one mechanism for both, so a stray catch (Exception e) swallows genuine bugs alongside expected failures — which is why catching broadly is a recognized code smell rather than a convenience. The other half of the story is that Java offers no checked-index alternative: where Rust has get returning Option, Java has only get that throws.

Two rules differ and both bite. A Java stream is single-use: calling a second terminal operation on the same stream throws IllegalStateException, which is why names.stream() is written twice above where Rust would need a fresh iter() for the same reason. And Stream is not Iterable, so it cannot be used in a for loop — the two worlds are joined only by forEach and by collection.stream(). Rust's Iterator is the one abstraction for both jobs.

Java calls this short-circuiting, and it applies to findFirst, anyMatch, limit and friends exactly as it does to find and take. The visible difference is what "not found" looks like: an Optional that prints as Optional.empty. The invisible one is that a Java stream may also be run in parallel, which is why its operations are required to be stateless and non-interfering in a way Iterator adapters are not.

Java's way is more verbose and considerably more capable out of the box: groupingBy, partitioningBy, toMap, joining, summingInt and counting compose into one another, and groupingBy in particular has no standard-library equivalent in Rust — the fold above is what you write instead. Rust's way needs no vocabulary at all for the common cases, since collect::<Vec<_>>() and collect::<HashMap<_, _>>() follow from the type alone.

The combiner exists because a Java stream may split its work across threads and then merge the partial results, so the accumulation has to be associative and the merge has to be expressible. Rust's fold is strictly sequential and therefore needs no such thing. Note mapToInt before sum: a Stream<Integer> has no sum at all, because sums are defined only on the primitive streams — one more place where erasure shows through.

A Gatherer is to an intermediate operation what a Collector is to a terminal one, and it is the thing the Stream API lacked for a decade: before it, anything not on the fixed list of built-in operations had to be written as a loop. windowFixed and windowSliding match chunks and windows; fold, scan and mapConcurrent round out the built-in set, and you can write your own. Rust's versions work on slices rather than iterators, which is why they can hand back borrowed views instead of new lists.

Stream.iterate also has a three-argument form — seed, predicate, next — which is a bounded loop written as a stream and has no direct Rust equivalent short of successors returning None. The boxed() call is the erasure tax again: LongStream yields primitive long values and toList() needs objects, so the conversion has to be requested. Rust's (1u64..) is an ordinary value of type RangeFrom, which is why it composes with everything.

A Java thread runs a Runnable, whose run method returns void, so a result has to be written somewhere both threads can see — here a one-element array, because a lambda cannot assign to a captured local. The idiomatic fix is an ExecutorService and a Future, which does return a value. Note throws InterruptedException on main: join is a blocking call, and every blocking call in Java is checked-exception territory.

This is the guarantee you are giving up, stated as plainly as it can be. counter.value++ is a read, an add and a write, and two threads interleaving those steps lose updates; the result is not merely unsynchronized but undefined under the Java memory model, so the value may also be stale indefinitely. Rust encodes the same rules in two auto-traits and refuses to compile the program. Java's equivalent protections — synchronized, volatile, the java.util.concurrent.atomic package — are all opt-in, and the next rows are where they go.

That is the whole difference and it is a large one. Mutex<Vec<String>> makes the data unreachable except through lock(); here, any code that forgets the synchronized block reaches the list anyway and nothing complains. There is also no poisoning: if a thread dies inside a synchronized block, the monitor is released and the next thread proceeds with whatever half-finished state it left, where Rust's lock() would return an Err. ReentrantLock in java.util.concurrent is the explicit alternative, with tryLock and timeouts that synchronized does not offer.

The one visible difference is memory ordering: Rust makes you name it on every operation, so Relaxed versus SeqCst is a decision you cannot avoid making, while Java's incrementAndGet is sequentially consistent and there is nothing to pass. The weaker orderings do exist in Java, under VarHandle, but almost nobody reaches for them. Note also that no Arc is needed — the collector already keeps the object alive as long as either thread can see it, which is the one place garbage collection is unambiguously simpler.

Rust's channel closes when the last Sender is dropped, which is what lets a for loop over the receiver terminate on its own — ownership doing double duty as a lifecycle signal. Java has no such moment, so a producer signals completion with an agreed sentinel value or a separate flag, and getting that wrong is how a consumer thread ends up blocked forever. The queue is also many-to-many rather than multi-producer-single-consumer, and it is bounded here by its constructor argument, which is the equivalent of sync_channel.

This is the concurrency feature with no Rust counterpart in the standard library. Rust's answer is async/await over an executor such as Tokio, which achieves the same density but splits the language in two — an async fn can only be called from another async fn, and the blocking and non-blocking halves of the ecosystem stay separate. Java kept one kind of code and moved the cleverness into the scheduler. 🚨 The Java column here shows correct code with no Run button: Compiler Explorer's sandbox allows one operating-system thread beyond main, and a virtual thread needs two — a carrier plus a VirtualThread-unblocker — so virtual threads cannot start there at any count.

The older Java mechanism, ThreadLocal, is the direct counterpart of thread_local! — a mutable per-thread slot, with the same problem visible above: someone has to remember to put it back, and forgetting leaks the value into whatever runs next on that thread. A ScopedValue is immutable and its lifetime is the run call, so it unwinds by itself, and it costs nothing per virtual thread — which is why it arrived alongside them. Rust has no equivalent of the scoped form; passing the value explicitly is the idiom.