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. In an interpolated string ($"…") the compiler checks every expression inside the braces, though a bad format specifier after the colon still fails only at run time; it is 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. Console.Error writes to standard error, a separate stream from Console.WriteLine's standard output, so where it appears depends on what is collecting the two — the servers that run the C# here report only standard output, so that line runs but does not show up below.

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 a method through an in parameter makes a defensive copy unless that method is marked readonly, because the compiler cannot otherwise 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. Neither carries a lifetime you can write, but the compiler still applies ref-safety rules — returning a ref to a local is a compile error — and a reference into the heap stays valid because the garbage collector keeps its target alive.

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 plain struct has no == at all unless it declares one (its Equals compares members). 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 goes out of scope without anyone having to ask — skipping it takes a deliberate std::mem::forget or a reference-counted cycle; 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 becomes collectable as soon as nothing outside it refers to it, and is reclaimed at some later collection, 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 or at unmanaged memory, and a ReadOnlySpan<char> can also point 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: a span has no lifetime you can write. The compiler instead tracks a coarse scope for each span — whether it came from the stack or from the heap — and rejects code that would let a stack span escape, backed by blanket restrictions on where a span may go.

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 may appear in an async method or an iterator only if it is never held across an await or a yield return. 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 write, the compiler pairs a coarse escape check with these blunter rules. 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 the places — the heap, a box, a lambda, a suspended method — where the question could not be answered.

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 whose value must be a constant expression (literals, and operators applied to other constants), 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: the type is fixed at the declaration and nothing can change it afterwards — though when the initializer is dynamic, the type var infers is dynamic itself.

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 two libraries can each define an extension method with the same name on the same type. Importing both makes the call an ambiguity error, and an instance member with that name silently wins over every extension.

#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 is a distinct type (typeof(int?) is Nullable<int>) — though boxing unwraps it, so GetType() on an int? holding 5 reports System.Int32. 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 and TryDequeue are the everyday members of a large 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 enforces less here than it seems to: it makes TryParse assign port on every path, so port is readable in the false branch too, where it holds the default 0. Nothing ties the value to the success the way match on a Result does.

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 only the thread it happens in (ending the program with status 101 when that is the main thread) unless the build sets panic = "abort", which stops the whole process at once, while a C# exception that nothing catches ends the whole process from whichever thread threw it — except inside a Task, which stores the exception and hands it only to whoever awaits the task. In a server both are usually caught at the request or task boundary, and that configuration is what decides whether one failure takes down more than its own request.

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 monomorphized 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> — 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, measured with sizeof and copied bytewise. Span<T> itself needs no such constraint: a span of structs that hold strings is fine. 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. In Rust the state is yours to write, as here, or to capture in a closure handed to std::iter::from_fn, so this is a real ergonomic win for C#. Note that a yield return method cannot take ref, in or out parameters, and cannot use a ref struct such as a Span<T> across a yield return — which rules out using one as a parameter at all — 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. The check reasons about values: a switch on an int that covers every range (< 0, 0, > 0) compiles with no warning, and so does one covering both bools. What it never proves is a closed set of names or types — a switch naming every member of an enum still warns, because any integer can be cast to the enum, and so does one naming every subtype of a 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: the compiler never treats a class hierarchy as closed — not even one whose base has a private constructor, so that no other code can add a subtype — and cannot prove the switch complete, so the _ arm is required to silence the warning. The layout differs too — a Rust enum is one value, its largest variant plus room for the tag, and here each value is a separate heap object with its own header. Discriminated unions have long been among the most requested C# features, and this pattern is what codebases write in their place.

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. There is no @, but the same job is done by naming a subpattern — value is int digit and >= 1 and <= 9 binds digit while testing it — and there is no 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 where the host installs one (a UI framework does; a console program has none), 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's Stream trait comes from the futures crate and is implemented by hand or with the async-stream macro. LINQ operators over async sequences — Select, Where, ToListAsync — are part of the standard library too, so both the language half and the library half are built in; older .NET versions took them from the separate System.Linq.Async package. 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: it builds iterator objects (adjacent stages such as Where and Select are fused into one) and each element crosses a delegate 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 general unsafe fn contract: a method marked unsafe needs an unsafe context at the call only when its signature mentions a pointer, a method may simply contain an unsafe block and ask nothing of its callers, and there is no notion of an unsafe trait. A project must opt in with <AllowUnsafeBlocks> before any of it compiles.

[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 sequential layout on the C# side — the default for a C# struct — 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 mostly agree: a Rust item is private unless marked pub, and a C# member defaults to private too. The difference is a top-level type, which defaults to internal — visible to the whole assembly, like pub(crate). 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: most change nothing by themselves and are read either by reflection at run time or by a compile-time tool, though the compiler acts on a few itself — [Obsolete("…", true)] turns every call into a compile error. 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.