Rust.CodeCompared.To/C#

println! is a macro because it type-checks its format string at compile time; Console.WriteLine is an ordinary method, and a mismatched {0} is a run-time FormatException rather than a compile error. Interpolated strings ($"…") are checked, so they are the closer analogue and the one to prefer. Only one file in a C# project may use top-level statements, so this is a script affordance rather than a change to how the language is organized.

A record or record struct generates a ToString() that prints the type name and every property, which is what #[derive(Debug)] gives you; a plain class or struct prints its type name and nothing else, so the missing derive shows up as Point rather than as a compile error. Format specifiers go after a colon inside the interpolation (:F2) rather than inside the braces before it (:.2). Note the helper record struct at the bottom — a top-level-statements file must declare its types after the executable code. One thing to expect when you run this row here: the Compiler Explorer runner reports stdout only on a successful run, so the Console.Error line is missing from the C# cell in the browser while it is there when you run the file locally.

dotnet add package is cargo add, NuGet is crates.io, and MyApp.csproj is Cargo.toml. The lockfile is packages.lock.json and — unlike Cargo.lock — it is opt-in, enabled with <RestorePackagesWithLockFile>, so a default .NET project does not have reproducible restores until someone turns them on. The output is an assembly plus a runtime dependency rather than a static binary, which is what the NativeAOT row at the end of this page is about.

A struct is copied on assignment, lives inline in whatever contains it, and is stack-allocated when it is a local — which is #[derive(Copy)] plus Rust's default placement. A class is a reference to a heap object with a header, and copying the variable copies the reference, which is Rc<T> without the count being visible. What C# does not give you is any control over when the class instance dies, and no compiler check that two references are not aliasing the same mutable data. Guidance in .NET is to keep a struct small (roughly 16 bytes or less) and immutable, because a large mutable struct copies more than you expect and behaves surprisingly when captured.

in is a read-only reference: the callee cannot assign to the parameter and no copy is made at the call. The catch a Rust reader should know about is that on a struct which is not declared readonly, calling any method through an in parameter makes a defensive copy, because the compiler cannot prove the method does not mutate — so in without readonly struct can be slower than passing by value. Marking the struct readonly removes the copies and is the reason the two features are always mentioned together. There is also ref (mutable reference) and out, but neither carries a lifetime, so nothing stops a reference from outliving what it points at — that is the garbage collector's job rather than the compiler's.

The with expression is Rust's struct-update syntax and produces a new instance with the named members replaced. The important difference is which comparison changed: a record is a class, so == is overloaded to compare members, while an ordinary class compares references and a struct compares members by default. That means == on a C# type does not tell you what it does without knowing how the type was declared — where Rust makes you write #[derive(PartialEq)] or implement it. record struct gives the same generated members with value semantics.

This is the tax the unified type system charges, and it is invisible where Rust makes you write Box::new. Reified generics avoid most of it — List<int> genuinely stores unboxed integers, which is what makes .NET generics good — but boxing returns whenever a struct is stored as object, passed to a non-generic API, or used through an interface it implements without a generic constraint. That last case is subtle: a where T : IComparable<T> constraint calls the method directly on the struct, while an IComparable-typed variable boxes first. It also explains a real trap: mutating a struct through an interface changes the box, not your original.

You stop writing moves, borrows, lifetimes and clone(), and the whole category of "fighting the borrow checker" disappears. What you get in exchange is a program where any two references can point at the same mutable object and no tool will say so — the bug class Rust exists to eliminate. In practice .NET codebases manage it the way every managed language does: immutability by convention, defensive copies at API boundaries, and record/readonly struct where it matters. The compiler will not help.

Dispose() is drop() and using is the scope that calls it — including the newer declaration form using var connection = …;, which disposes at the end of the enclosing block and reads almost exactly like a Rust binding. The gap is that nothing requires the using: forgetting it compiles fine and leaks the handle until a finalizer runs, if there is one. The analyzer warning CA2000 catches many cases and is off by default. Rust's guarantee is that drop runs when the value dies and there is no way to forget; C#'s is that Dispose runs if you remember to ask. That is the single biggest thing a Rust reader gives up here.

A .NET cycle is collected as soon as nothing outside it is reachable, so the parent-child back-reference that costs a Rust program a Weak and a RefCell is just two fields. WeakReference<T> exists and is for caches, not for breaking cycles. What you pay is that the release is non-deterministic: you cannot say when the memory comes back, allocation-heavy code produces collection pauses, and Arc<Mutex<T>>'s explicit cost is replaced by an implicit one that shows up in a profiler rather than in the type.

ReadOnlySpan<T> is &[T] and Span<T> is &mut [T]. Both can point at an array, at stack memory, at unmanaged memory, or at a string, so a parser written against ReadOnlySpan<char> works on all of them without allocating — the same reason Rust code takes &str rather than String. Slicing is span[1..4] with range syntax, or Slice(1, 3) with a start and a length. The safety difference is the next row: nothing gives a span a lifetime tied to its source, so the compiler protects you by restricting where a span may go rather than by tracking what it points at.

A ref struct cannot escape to the heap: it may not be a field of a class, may not be boxed, may not be captured by a lambda, and — until [UnscopedRef] and the C# 13 relaxations — could not be used in an async method or an iterator. The reason is exactly the one a Rust reader will guess: a span into stack memory must not outlive that stack frame, and with no lifetimes to check the compiler enforces a blunter rule instead. Compare the two declarations above: Rust carries <'a> and permits the type anywhere the lifetime is satisfied; C# carries no lifetime and forbids the type from anywhere the question could arise.

Assigned to a Span<T>, stackalloc needs no unsafe block; assigned to a raw pointer, it does. The important operational difference from a Rust [u8; 16] is that the size may be a run-time value, which means stackalloc in a loop, or with a caller-supplied length, is a stack-overflow waiting to happen — the standard pattern is length <= 256 ? stackalloc byte[length] : new byte[length], and for larger buffers ArrayPool<T>.Shared. Bounds are still checked on every access, so this is not the same performance profile as the Rust version, though the JIT elides many of the checks in a foreach.

There is no let-versus-let mut distinction to carry over: const is a compile-time constant that must be a literal expression, and readonly applies to fields rather than locals. So the immutability discipline moves from the compiler to the type — a record, a readonly struct, an ImmutableArray<T> — and locals are simply mutable. var is only inference, never dynamic typing: the type is fixed at the declaration and nothing can change it afterwards.

A plain + in C# wraps, and checked makes it throw OverflowException; the project-wide setting <CheckForOverflowUnderflow>true</CheckForOverflowUnderflow> flips the default for the whole assembly, which is the closest thing to Rust's debug behavior and is off in every default template. Rust panics in debug and wraps in release, with wrapping_, checked_, saturating_ and overflowing_ as the explicit forms. C# has checked/unchecked and no saturating arithmetic on the built-in operators. Note also that C# promotes byte arithmetic to int, so small + 10 is 260 and the wrap only happens at the cast.

using X = Y; is type X = Y;: file-scoped, purely a name, and interchangeable with the underlying type. The newtype is a readonly record struct with one field, which is the standard .NET spelling and gets equality, ToString and deconstruction for free. It is a zero-cost abstraction in the same sense Rust's is — a one-field struct has no header and is passed in a register — so the safety is genuinely free. What C# lacks is Rust's coherence rules, so nothing stops two libraries from defining conflicting extension methods on the same type; the compiler picks by scope and you may not notice.

#if is a genuine preprocessor directive: the excluded text is not parsed, so it need not even be valid C#, and an IDE greys it out and stops checking it — which is exactly how #if blocks rot. Rust's #[cfg] is an attribute on an item the parser has already read, so excluded code must still be syntactically valid and the tooling can see it. Symbols come from <DefineConstants> in the project file, which is where a Cargo feature ends up. For platform checks specifically, prefer the run-time OperatingSystem.IsLinux() — the JIT folds it to a constant and it keeps every branch compiled and checked.

string? and string are the same type at run time — the annotation is metadata the compiler reads, and violating it is a warning, not an error, unless the project sets <WarningsAsErrors>nullable</WarningsAsErrors>. It can be defeated by the ! null-forgiving operator, by reflection, by deserialization, and by any library compiled without the feature. Option<T> by contrast is a real enum you cannot look inside without matching. The operators map cleanly — ?. is map, ?? is unwrap_or, ??= is get_or_insert_with — and there is no and_then chain because ?. already short-circuits the whole expression. Note also that Option<T> nests (Option<Option<T>>) and string?? does not exist.

It has HasValue and Value where Option has is_some() and unwrap(), throws InvalidOperationException rather than panicking on an empty unwrap, and cannot be confused with the non-nullable type by any amount of reflection. So C# has two entirely different nullability mechanisms with one syntax, and knowing which one a ? means requires knowing whether the underlying type is a struct or a class. The TryParse pattern with an out parameter is the .NET idiom for a fallible parse and is what str::parse().ok() does.

A C# method that can fail looks exactly like one that cannot, so the only way to know is documentation or the source. There are no checked exceptions — that was a deliberate rejection of Java's design — so the compiler never asks you to handle or declare anything, and an unhandled exception terminates the process the way a panic does. The type hierarchy is a class tree rooted at Exception rather than a per-function enum, so catch (FormatException) is the analogue of matching one variant and catch (Exception) of matching them all. The next two rows cover what a Rust reader will reach for instead.

TryParse, TryGetValue, TryAdd, TryDequeue are the whole family, and they exist because exceptions in .NET are expensive — roughly microseconds, involving a stack walk — so using one for an expected outcome is a real performance problem as well as a design smell. The compiler does enforce something here: out var port is definitely assigned only where the method returned true, so reading it in the false branch is an error. That is a narrow version of what match on a Result gives you, and it is as close as the built-in mechanism gets.

With exceptions you do not need one — the propagation is the default and the intermediate function says nothing — which is exactly the trade: propagation is free and invisible rather than cheap and explicit. With the Try pattern, propagation is entirely manual, and a three-step chain becomes the nested shape above, which is why Try methods are used at boundaries rather than threaded through a call graph. Libraries such as LanguageExt and ErrorOr supply a real Result type with monadic combinators, and they are used in some teams, but they cut against the grain of the base class library and nothing in it will accept one.

assert! becomes an explicit throw, and .NET 8 added a family of guard helpers — ArgumentNullException.ThrowIfNull, ArgumentOutOfRangeException.ThrowIfNegativeOrZero — which read like assert! and produce a properly typed exception with the argument name filled in by the compiler. debug_assert! is Debug.Assert, compiled out of a release build exactly as its Rust counterpart is, which means neither is safe for validating real input. The genuine difference is the failure mode: a panic unwinds and, by default in a binary, aborts the process, while an uncaught exception unwinds to the top of the thread — so a request handler that throws takes down one request and a Rust one that panics may take down the task or the process depending on configuration.

Two differences matter. A C# interface must be implemented where the type is declared: you cannot write impl MyTrait for String for a type you do not own, so the standard workaround is an extension method, which is resolved statically and therefore cannot be dispatched on dynamically. And a default interface method is only reachable through the interface — new French().Greeting() does not compile without a cast, because the method is not a member of the class. That is a genuine trap and the reason default interface methods are used far less than they might be. There are no coherence rules to worry about either, since the "implement a foreign trait for a foreign type" case is simply impossible.

An interface-typed variable is Box<dyn Trait>: a reference plus a method table, dispatched at run time. There is no Box because every class instance is already a reference, and no object-safety rules, because a C# interface may have generic methods, static members and everything else — the restriction Rust needs in order to build a vtable does not arise the same way. A generic method with an interface constraint (static double Total<T>(…) where T : IShape) is the impl Trait equivalent, and it really is monomorphised for value types, which the next section covers.

This is the direct counterpart of T: Add<Output = T>, and .NET 7 shipped a whole hierarchy of these interfaces — IAdditionOperators, INumber<T>, IParsable<T>, ISpanFormattable — which is std::ops and num-traits arriving in the base class library at once. Before this, a generic Sum over arbitrary numeric types simply could not be written and every library faked it with per-type overloads or runtime dispatch. Two remaining differences: C# operators are declared static on the type rather than through a separate impl block, and there is no associated-type syntax, so the output type is another type parameter.

It is resolved statically — it compiles to Extensions.Shout(text) — so it is not dynamic dispatch, cannot be overridden, and loses to a real member method of the same name, which means adding a member with your extension's name silently changes every call site. In exchange it is scoped by using rather than by a coherence rule, so the blast radius is one file and two libraries adding the same name simply need one of them not to be imported. This is how LINQ works — every one of those operators is an extension on IEnumerable<T>. What it cannot do is make a foreign type satisfy an interface, so impl ForeignTrait for ForeignType genuinely has no counterpart.

For a value type argument the runtime generates specialized machine code exactly as monomorphization does, so List<int> stores unboxed integers and a generic method over int has no indirection. For a reference type argument all instantiations share one compiled body, since every reference is the same size — so there is one code path for List<string> and List<object> alike. The result is Rust's performance where it matters and none of the code bloat where it does not, which is a genuinely good trade. What you also get is a whole reflective capability Rust has no equivalent for, and no PhantomData, since an unused type parameter is simply allowed.

The constraint vocabulary is different in kind: alongside interface constraints C# has class, struct, notnull, unmanaged, new() and base-class constraints, several of which are about memory layout rather than behavior. unmanaged is the interesting one for a Rust reader — it means the type contains no references at all, so it can be pointed at and copied bytewise, which is what makes Span<T> over a struct sound. There is no negative reasoning and no specialization, and — until static abstract members — no way to require an operator, which is why IComparable<T>.CompareTo stands in for PartialOrd here.

IEnumerable<out T> is covariant — out meaning T appears only in output positions — and Action<in T> is contravariant. Rust infers variance from usage and never asks you to write it, and because there is no subtyping between concrete types the question mostly does not arise; the place it does is lifetimes, where &'long T coerces to &'short T. Two C# limits worth knowing: variance works only on interfaces and delegates, never on classes, so List<Square> is not a List<IShape> (which would be unsound, since you could add a Circle); and it works only for reference types, because a covariant conversion of a value type would need a representation change.

Dictionary's indexer throws on a missing key rather than returning an option, so TryGetValue is the everyday form and GetValueOrDefault is the terse one. There is no &mut, so nothing prevents a collection from being mutated while something else holds a reference to it — foreach detects the case at run time and throws InvalidOperationException, which is where Rust gives you a compile error instead. Immutable collections live in System.Collections.Immutable, and the newer FrozenDictionary trades build cost for faster lookups.

So the flag emoji, one grapheme built from two code points, is 8 bytes in UTF-8, 2 chars in Rust, and Length == 4 in C#, because each code point needs a surrogate pair. Anything doing real text work reaches for StringInfo or Rune, which is .NET's char-as-code-point type. The owned/borrowed split has no counterpart — a C# string is an immutable heap object and there is no &str, which is why ReadOnlySpan<char> exists and why string.Substring allocates where &text[..3] does not. StringBuilder is the mutable builder, since += in a loop allocates each time.

filter is Where, map is Select, flat_map is SelectMany, fold is Aggregate, collect is ToList/ToArray/ToDictionary, and take/skip keep their names. The evaluation model is the same — nothing runs until something enumerates — with one behavioral difference worth internalizing: a LINQ query can be enumerated twice, and it re-runs the whole chain, so a query over an expensive source is a performance trap that a once-only Rust iterator cannot be. The cost model differs too: every LINQ stage is a delegate call through an interface, where Rust's adapters inline into a loop, so a hot path in .NET is written as a foreach.

A yield return method is rewritten into a state machine class implementing IEnumerator<T> — literally the struct-plus-next shape, generated. That is far less to write, and the trade is that you cannot see or control the state, cannot implement size_hint, and get no specialized ExactSizeIterator-style behavior. Rust's generators are still unstable, so writing an iterator by hand is the norm there and this is a real ergonomic win for C#. Note that a yield return method cannot take ref/out parameters or a ref struct, for the same escape reason as earlier.

The consequence of Rust's design is the turbofish and the occasional need to annotate the binding; the consequence of C#'s is that ToList, ToArray, ToHashSet, ToDictionary and ToLookup are five names you learn. ToLookup has no direct Rust counterpart — it is a one-to-many dictionary, so it is collect into a HashMap<K, Vec<V>> in one call, and it returns an empty sequence rather than throwing for a key it does not have. ToDictionary throws on a duplicate key, where Rust's collect into a HashMap silently keeps the last.

The arms map closely: 1..=9 becomes >= 1 and <= 9 (C# has no range pattern for numbers, though it does for lists), a guard is when rather than if, and _ is the discard in both. Exhaustiveness is where they part company. C# checks it and emits a warning, then compiles a switch that throws SwitchExpressionException at run time if nothing matched — where Rust simply refuses to compile. Since a C# reference can always be null and an int can always be some unlisted value, a true closed-world check is only possible over an enum or a sealed hierarchy, which the next row covers.

The standard workaround is an abstract record with sealed record subtypes, matched by type pattern — which gets you the shape and most of the ergonomics. What it does not get you is the closed world: any assembly can add a third subtype unless the base is declared with a private constructor, so the compiler cannot prove the switch is complete and the _ arm is required to silence the warning. The layout differs too — a Rust enum is one value the size of its largest variant, and this is three heap objects with headers. Discriminated unions have been the most-requested C# feature for years and a proposal is in progress; until it lands, this pattern is what every codebase uses.

A C# tuple is ValueTuple, a mutable struct, so it is a value type like Rust's and is passed in registers when small. Elements may be named — (int quotient, int remainder) — which makes a multi-value return self-documenting; the names are compiler metadata rather than part of the runtime type. Positional patterns work on any type with a Deconstruct method, and records generate one, so if (shape is Square(var side)) matches a record's components the way a Rust struct pattern does. What is missing is @ bindings on subpatterns and any equivalent of ref/ref mut in a pattern, since binding modes are a borrow-checker concept.

The .. is the slice pattern and may appear once, optionally binding: [var first, .. var middle, var last]. Two differences. The var keyword is required on each binding, since a bare identifier in a C# pattern would be a constant to compare against. And this switch is exhaustive in the compiler's view for a non-null array, but a null array falls through and throws SwitchExpressionException — which is the recurring theme: C# checks the cases you wrote and cannot rule out null.

Calling a C# async method starts it immediately and returns a Task representing work already in flight; await only waits for the result. So creating a task and awaiting it later is how you get concurrency, and forgetting to await one leaves it running unobserved with its exception swallowed until finalization — the "fire and forget" hazard that a cold future cannot have. There is also no executor to choose or pass around: the runtime supplies a thread pool and a synchronization context, so #[tokio::main] has no counterpart and nothing is generic over it. ValueTask<T> exists for the case where the result is usually already available and allocating a Task is waste.

Cancellation is the real difference. Dropping a Rust future cancels it — cancellation is a consequence of ownership — while a .NET Task cannot be cancelled from the outside at all. Instead a CancellationToken is threaded through every call as an explicit parameter, and each operation is responsible for checking it; a method that ignores its token simply runs to completion. That is more plumbing and it is also more predictable, since Rust's cancel-at-any-await-point is a well-known source of subtle bugs where a future is dropped between two operations that had to happen together.

async IAsyncEnumerable<T> combines async and yield return, and await foreach consumes it; the compiler generates the state machine. Rust has Stream in the futures crate, implemented by hand or with the async-stream macro, and it is still not in std. LINQ operators over async sequences come from the separate System.Linq.Async package, so the built-in support is the language half rather than the library half. Cancellation flows in through [EnumeratorCancellation] on a token parameter, which is the plumbing the previous row described.

There is no Send or Sync: any object may be touched from any thread, and no marker trait or compiler check stands between you and a data race. The lock is not attached to the data either — lock (padlock) guards a region of code by convention, where Mutex<T> makes the data unreachable without acquiring it, which is the design difference that matters most. Arc disappears because every reference is shared and the collector handles the count. What .NET offers instead is a good library — Interlocked, ConcurrentDictionary, Channel<T>, SemaphoreSlim — and a documented memory model, plus analyzers that catch some misuse. None of it is a proof.

The correspondence is close: CreateUnbounded is mpsc::channel, CreateBounded is sync_channel, and Writer.Complete() is dropping the sender — except that here it is an explicit call, because there is no ownership to observe. Multiple producers and multiple consumers are both supported and configurable, where std::sync::mpsc is single-consumer by construction. What is lost is the compiler's help: nothing prevents you from continuing to hold and use a value after sending it, so the "channels transfer ownership" mental model becomes a convention you keep in your head.

Func<A, R> is a function returning a value and Action<A> is one returning void, which is the split C# has instead of a unit type — the two are not interchangeable and the arity is baked into the type name. Capture is always by reference to a compiler-generated object, so a captured local is heap-allocated and outlives its scope: that is FnMut with no borrow checker, and it is why a lambda in a loop capturing the loop variable used to be a classic bug (fixed for foreach in C# 5, still live for a C-style for). There is no move; copy a value into a new local before the lambda if you need it frozen. A lambda that captures nothing is cached and allocates once.

A C# lambda that captures nothing is cached in a static field, so it allocates once for the program; one that captures becomes a heap object allocated per call. The static modifier on a lambda (C# 9) is a compile-time assertion that it captures nothing — the closest thing to the guarantee a Rust closure gives you by construction, and worth using in a hot LINQ chain. The chain itself is not free either: each stage is an iterator object and each element crosses a virtual call, where the Rust version compiles to one loop. That is why performance-sensitive .NET is written as foreach, and why Span<T>-based code avoids LINQ entirely.

The extra keyword is fixed, and it exists for a reason with no Rust analogue: the garbage collector moves objects during compaction, so a pointer into a managed array is only valid while that array is pinned. Forgetting fixed is a compile error for a local, and pinning for too long fragments the heap — which is why Span<T> and ref exist as the safe way to do most of what pointers were used for. There is no unsafe fn that callers must acknowledge and no notion of an unsafe trait; a method may simply contain an unsafe block, and the project must set <AllowUnsafeBlocks> to compile at all.

[LibraryImport] is the modern replacement for [DllImport]: it is a source generator, so the marshaling code is generated at compile time, is visible, and works under NativeAOT — which [DllImport]'s runtime marshaling does not fully. The rules to hold on to: only blittable types cross for free, which means no String, no Vec, no enum with a payload; a struct needs [StructLayout(LayoutKind.Sequential)] on the C# side and #[repr(C)] on the Rust side; and any pointer Rust allocated must be freed by calling back into Rust, because the two allocators are different. Ownership is entirely by documentation once the boundary is crossed.

What you gain is what a Rust reader expects: no runtime to install, no JIT warm-up, a fast, predictable start, and a much smaller memory footprint — which is why it is the default choice for a CLI or a serverless function. What you give up is the reflection-heavy half of the ecosystem, because the trimmer removes code nothing statically references: Reflection.Emit is unavailable, and reflection-based serializers, ORMs and dependency-injection containers either need source-generated equivalents or do not work. The binary is also larger than the Rust equivalent, since the garbage collector and the type system's runtime support come along. Both a Rust binary and an AOT one still have a runtime; the difference is how much of it, and whether it can compile new code while running.

The consequence is visibility: a Rust test module can see private items because it is a child module, while a C# test project sees only public members unless the main project adds [assembly: InternalsVisibleTo("MyApp.Tests")]. There is no built-in framework — xUnit, NUnit and MSTest are packages, with xUnit the common default — and no equivalent of cargo test running doc tests, because doc comments are XML for tooling rather than compiled examples. What .NET has that Cargo does not is first-class parameterized tests ([Theory] with [InlineData]) without a macro crate.

A namespace is purely a name and carries no visibility at all — namespace Billing nested inside another gives you a longer name and nothing else. An assembly is the compilation unit, and it is what internal (the default for a top-level type) is scoped to, making it the equivalent of pub(crate). There is no pub(super) or pub(in path). Visibility defaults also invert: a Rust item is private unless marked pub, while a C# member defaults to private and a top-level type defaults to internal. using is a compile-time alias with no runtime effect, so there are no import cycles and no import-time side effects.

An attribute is metadata attached to a declaration: it changes nothing by itself, and is read either by reflection at run time or by a compile-time tool. A source generator is that compile-time tool — a Roslyn analyzer that sees the whole compilation and adds new source files to it — which is the closest thing to a procedural macro, and is how System.Text.Json, regex compilation and [LibraryImport] avoid reflection under NativeAOT. Two limits against a derive macro: a generator can only add code, never rewrite what you wrote, and it hooks in through a partial declaration rather than by transforming your type. There is no macro_rules! equivalent at all; that work is done by generics and by [CallerMemberName]-style compiler-supplied arguments.