C#.CodeCompared.To/Odin

This is roughly the static void Main ceremony C# spent two versions removing, and Odin keeps it deliberately: a file is a compilation unit with no implicit entry point, so nothing runs merely because it was loaded.

This is the largest genuine loss on the page and it should inform whether Odin fits the job at all. If your instinct on any new problem is to search nuget.org, no language feature compensates for that instinct being unavailable — though for the game and graphics work Odin targets, the dependency list is usually short and mostly C libraries anyway.

The :: constant is genuinely closer to C#'s const than to static readonly: it has no runtime storage at all. Note also that Odin has no static anything, because there is no class for a member to be static on.

The trade is that everything the CLR does for you at runtime has to be decided at compile time instead. You gain a binary with no startup cost and no deployment prerequisites; you lose runtime code generation, assembly loading, and every tool that depends on inspecting IL.

C# makes you choose class or struct per type and then live with the aliasing rules that choice implies — which is why "is this a reference or a copy?" is a question you ask about every unfamiliar type. In Odin the answer is always the same, and the exception is spelled out at the call site.

C# 8's nullable reference types are annotations the runtime never sees: null! silences the compiler and the NullReferenceException still arrives. Odin removes the category instead of annotating it — and where absence is genuinely meaningful, Maybe(T) in the unions section makes it part of the type.

The missing piece for anyone porting business logic is decimal. C# gives you exact base-ten arithmetic as a primitive; Odin has i128 and nothing else, so amounts become integer counts of cents and the rounding rules become yours to write.

C# hides widening conversions and lets a library author add more with implicit operator, which is convenient right up to the point where an unintended conversion silently changes what an expression means. Odin removes the mechanism entirely — there is no operator overloading of any kind, which also means + always means addition.

This is one of the clearest wins for a .NET reader, because Span<T> is the shape you already wanted everywhere and could only use in the places the runtime permitted. The cost is that nothing checks whether the memory behind a slice is still alive — the borrow rules ref struct encodes are now yours to keep.

Which procedures allocate is the thing to learn here, and it is entirely predictable — anything returning a fresh string or slice does, anything only reading (like strings.contains) does not. That distinction is invisible in C# because the GC absorbs it.

%v is the closest thing to ToString(), and it works on structs, slices, maps, enums, and unions with no code from you — the compiler emits type information and fmt walks it. Where C# calls a virtual method the type overrides, Odin reads the layout.

The mechanism is the same one StringBuilder uses; the difference is that builder_destroy is a line you write and the returned string is a view rather than a copy. That view is faster and is also a lifetime you now have to think about.

C#'s char is a UTF-16 code unit, which is why "🐦".Length is 2 and a foreach over that string sees two halves of nothing. Odin's split is honest about the two units that actually matter — bytes for storage, runes for characters — and never invents a third.

C# ships both shapes and the throwing one is the shorter to type, which is why it turns up in code paths that then need a try. Odin ships only the reporting shape, so the failure always arrives as a value at the point it happened.

The growth strategy is the same amortized doubling List<T> uses. The two differences are that the buffer needs an explicit delete, and that numbers[:] hands out a view of it — passing the collection costs two words rather than a reference plus indirection.

C# arrays are reference types, so var alias = array shares the storage and every helper that takes an array can mutate the caller's data. Odin separates the two ideas: the array is the storage and copies, the slice is the view and aliases, and which one you meant is visible in the code.

Indexing a Dictionary with a missing key throws; indexing an Odin map returns the value type's zero. That makes a map of counters work without TryGetValue ceremony, and it makes the second return value the only honest way to distinguish "stored zero" from "absent".

C#'s [Flags] is a convention layered on an integer enum: you assign the powers of two by hand, HasFlag boxes unless the JIT saves you, and nothing stops (Permission)99. The bit_set is a real type where the bit positions are the compiler's job.

Losing yield return means losing the compiler-generated state machine that made lazy sequences cheap to write. What replaces it is either filling a buffer the caller owns (fast, eager, no allocation surprises) or a hand-rolled cursor procedure — both of which are what the C# compiler was generating for you anyway.

This is the biggest day-to-day adjustment on the page, larger than losing the garbage collector, because it touches every method you write rather than one subsystem. The honest consolation is real: the C# version allocates an iterator per stage and pays a delegate call per element, and the Odin version is one pass with nothing allocated.

The C# version quietly demonstrates why that matters: scale captured the variable, not its value, so changing multiplier changed what scale does. In Odin the state is a value you passed, so there is no shared mutable binding to be surprised by, and no allocation you did not ask for.

This covers most of what non-capturing delegates do — a comparator, a callback, a strategy chosen at runtime. Events are the visible gap: a C# event is a multicast delegate with subscribe and unsubscribe built in, and here it is a slice you manage yourself.

A comparator is the ideal case for procedure values, because it genuinely needs nothing from the surrounding scope. The moment you want OrderBy(item => item.DistanceTo(origin)) where origin is a local, the pattern breaks and the loop comes back.

The if statement; condition form is the piece C# does not have: the variable exists only inside the branch, so a value used for one test cannot leak into the rest of the method. C#'s ?? maps to or_else, which the optionals section covers.

What is missing is the switch expression: Odin's switch is a statement, so the C# habit of assigning its result needs a declared variable first. Type patterns move to switch in over a tagged union, which the interfaces section covers, and property patterns have no equivalent at all.

What Odin adds is labeled break and continue, which let an inner loop exit an outer one by name. C# needs goto or a flag variable for the same job.

The advantage over using is that it works on anything, not just an IDisposable, and the release sits on the line after the acquisition rather than being implied by a block. The disadvantage is symmetrical: nothing reminds you to write it, where the compiler at least warns about an unused disposable.

C# has labels only for goto, which is why this pattern reads as a code smell there and turns up as a found flag or an extracted method instead. Odin makes the structured version the obvious one.

There is no method-versus-function distinction because there are no classes for a method to belong to. Everything lives at package scope, and the thing a procedure operates on is simply its first parameter — the type_verb naming convention does the work a receiver does in C#.

This lands almost exactly on C#, down to the ordering freedom. The one difference worth knowing is that an Odin default must be a compile-time constant, so the DateTime.Now-style default that C# also forbids stays forbidden, and there is no [CallerMemberName] family.

C# marks a ref at both the declaration and the call, which Odin matches with ^ and &. The genuine simplification is out: multiple return values remove the need for the concept, and each one keeps its own type instead of being an assignment obligation the compiler tracks.

The shape matches params closely. What differs is the cost: C# allocates a real int[] on the heap for each call unless the JIT can prove otherwise, while the Odin slice points at a temporary the compiler laid out on the stack.

C# treats a value parameter as an ordinary mutable local, which is why "reassign the parameter, then use it" is a common idiom and also why a debugger can show a value the caller never passed. Odin removes the ambiguity at the cost of one extra local.

The signature now carries what C# expresses through convention and modifiers: ^Rectangle can mutate, Rectangle cannot, and there is no way to hide either behind a property setter. size_of(Rectangle) is exactly the sum of its fields — no sync block, no type handle.

The everyday consequence is that no assignment can run code. A C# property makes temperature.Celsius = -300 throw from what looks like a store; in Odin the validation has a name and a return value, so a reader can see that it was called and what it answered.

A C# constructor can refuse to produce an object by throwing. An Odin constructor cannot, so it returns the failure as a value — and a caller who ignores it gets a zeroed struct, which is at least a defined state rather than a half-built object.

C# needed the record keyword because a class defaults to reference equality and a hand-written Equals/GetHashCode pair is easy to get wrong. Odin has no such default to fix. What it does lack is with — a copy and an assignment, which is two lines instead of one.

Nothing here dispatches. The whole point of Describe calling a virtual Speak is that a subclass changes the answer, and Odin has no mechanism for it — there is no vtable, so a procedure taking a Dog takes a Dog. Runtime polymorphism must be built explicitly, which the next section does.

This inverts the trade an interface makes. Adding a shape in C# costs nothing and touches nothing; adding one here makes the compiler point at every switch that now has a hole. Adding an operation is the reverse: a new interface method breaks every implementer, while a new procedure over the union breaks nothing.

This is what the CLR builds for an interface call anyway: a target reference plus a method slot. Writing it out costs the type checking and the tooling, which is exactly why the tagged union above is the better default and this is reserved for genuinely open plugin boundaries.

That non-copying design is the whole difference from boxing. C# heap-allocates when an int becomes an object, which is why Span<T>, generics, and ArrayPool exist to avoid it. Odin sidesteps the allocation and hands you a lifetime rule instead, which is why any belongs in printing and debugging code rather than in stored data.

The loss is the fluent chain, and it is the same loss as LINQ's: text.Trim().ToLower().Shout() becomes nested calls or intermediate variables. What you gain is that a call to shout is findable by grepping for shout ::, with exactly one result and no using directive deciding which one applies.

The cost is that every frame between the failure and the handler must declare and forward the error, where a C# exception flies past twenty of them untouched. The benefit is that a signature tells you exactly what can go wrong, which no C# signature has done since checked exceptions were rejected.

This gets error-value code close to the density of exceptions for the common "pass it up" case. What it deliberately will not do is skip frames — every procedure on the path still declares the error, so the route from failure to handler is written down rather than inferred from a stack trace.

The placement is the real improvement. A finally block sits at the bottom, far from the acquisition it balances, and a long try can hide whether they still match. A defer sits on the next line, so a reviewer sees both at once.

C# routes both categories through Exception, which is how a catch (Exception) at a request boundary ends up swallowing a null-dereference bug and logging it as a failed request. Odin enforces the split: expected failures are return values, impossible states abort.

For a .NET reader this is the familiar argument in its strongest form. Every trick the runtime offers to dodge the collector — Span, stackalloc, ArrayPool, struct over class, server GC tuning, TryStartNoGCRegion — exists because allocation is cheap and collection is not. Odin removes the collector rather than the allocation, which is the same bargain Unity made when it built Burst and DOTS.

A linked structure is where the missing collector bites hardest, because ownership stops being obvious — two nodes pointing at each other have no natural owner, and neither defer free knows about the other. The practical answer is the arena two rows down: allocate the whole graph in one region and drop the region.

Reading Odin's standard library becomes a habit of asking "does this return something new, or a view into what I passed?" — strings.join builds and must be deleted, strings.has_prefix only looks. Getting it wrong leaks rather than crashing, which is why the tracking allocator below exists.

This is the feature that makes life without a collector practical, and .NET has no counterpart. Lifetimes that are genuinely bulk — everything a request touched, everything a frame drew — stop needing per-object ownership: allocate into the arena and reset it when the phase ends.

This is the closest Odin comes to "just make a string and forget it", and the difference is where the sweep happens: you call free_all at a boundary you picked, rather than a collector choosing a moment you did not. For a frame loop that distinction is the whole ballgame.

A leak means opposite things in the two runtimes. In .NET it means something still holds a reference and the collector is right to keep the object, so finding it means capturing a dump and walking a retention graph. Here it means a delete was never written, and this tool names the line that allocated it.

The mechanism is closer to C++ templates than to .NET generics: every instantiation is compiled separately, so > works if the concrete type supports it and no IComparable constraint is needed. What you lose is the shared runtime representation — reflection over an open generic type, and List<T> for reference types sharing one compiled body.

C# generics are constrained to type arguments, which is why fixed-capacity buffers, matrix dimensions, and unit-of-measure tricks all end up as runtime values or code generation. This is the same capability C++ non-type template parameters and Rust const generics provide, and it is genuinely absent from .NET.

Odin has no preprocessor at all, and when is why it does not need one. Unlike #if, it has real scoping and real type checking on the surviving branch, and it composes with $ parameters so a generic procedure can specialize its body per type.

The line is between inspecting and acting. You can ask what fields a struct has; you cannot invoke something discovered by name, construct a type from a string, or emit code, because there is no method table and no JIT. Every .NET library built on those — the serializers, the DI containers, the ORMs, the mocking frameworks — has no Odin analog.

C# decouples namespace from folder, which is flexible and also why a large solution needs conventions and analyzers to keep the two aligned. Odin ties them together and makes qualification mandatory rather than conventional, so json.marshal and string_helpers.to_upper can never shadow each other.

C#'s six levels exist because inheritance needs protected and assemblies need internal; Odin has neither concept, so two levels cover it. The other difference is that private really is unreachable — no reflection, no InternalsVisibleTo, no dynamic proxy reaching in.

What genuinely has no counterpart is the source generator. .NET's move toward AOT replaced runtime reflection with compile-time generation, and Odin has neither — the equivalent work is done by $ parameters and when, or by a script you run yourself before building.

A C# enum is an integer with names attached, which is why (Level)99 is legal and Enum.IsDefined exists. An Odin enum is a distinct type, and the enum-indexed array is the piece with no C# analog at all — a lookup table the compiler proves is total.

This is the discriminated union C# has been asking for through five language versions. The object version above boxes every value type, needs a _ arm the compiler cannot prove is unreachable, and gives no warning when a fourth case appears — the union fixes all three.

C# has two unrelated mechanisms here: Nullable<T> is a real struct the runtime enforces, while string? is an annotation erased at compile time that produces warnings and nothing more. Maybe(T) is one mechanism, enforced, for every type — closer to F#'s option than to anything in C#.

Both shapes are idiomatic in Odin: the (value, error) pair from the errors section reads better when the caller usually wants the value, and this union reads better when the two outcomes are genuinely equal alternatives. The C# equivalent needs a record hierarchy and still cannot be checked for exhaustiveness.

This is a real gap and worth being clear about. async/await makes ten thousand concurrent I/O operations cheap on a handful of threads, and Odin has no equivalent — a thread per operation is the model. For the CPU-bound, frame-oriented work Odin targets that is the right shape; for a web service handling many idle connections it is not.

Putting the mutex inside the struct it guards is the convention worth adopting: a C# lock (gate) leaves the association between lock and data implicit, and only a comment says which fields gate covers. Odin also has sync.atomic_add for the counter case, which needs no lock at all.

For a Unity developer this is the headline. A loop touching only x fills every cache line with useful data instead of skipping over y and alive, and that is precisely what DOTS, NativeArray, and Burst were built to achieve. Odin spells it as one directive on the type.

This is one of the few places on the page where Odin is the terser language. System.Numerics hand-writes operators for a handful of fixed sizes and leaves everything else to Vector<T> or a loop; here it is a property of the array type, so [7]f64 works the same way [3]f32 does and both compile to SIMD instructions.