Go.CodeCompared.To/Odin

The remaining differences are cosmetic — procedure names are snake_case rather than exported-by-capital, and there are no semicolons or parentheses where Go would not need them either.

Once that clicks, the whole declaration grammar collapses to two forms: :: for anything known at compile time, and name := value or name: Type for a runtime variable. Declaration order at file scope does not matter, as in Go.

This is the habit hardest to unlearn — renaming Foo to foo changes nothing about who can see it. Odin also gives a finer scope than Go offers at all. Community style is snake_case for procedures and variables, Ada_Case for types.

There is no module system and no remote import path. Note also that strings.to_upper allocates and needs a delete: with no garbage collector, any standard-library call returning a new string hands you ownership of it.

Odin adds one thing Go deliberately withholds: buffer: [1024]byte = --- opts out of zeroing, leaving the memory uninitialized as a performance escape hatch.

u32be and u32le byte-swap on access, which removes most hand-written encoding/binary code when parsing a file or wire format. Go has no built-in 128-bit integer at all.

If you have internalized Go's constant rules they carry over unchanged, including the compile-time rejection of a constant that will not fit its target type.

That buffer-passing style is the recurring theme once the garbage collector is gone: the standard library prefers to let you own the memory rather than hand you some.

The arithmetic lowers to SIMD where the target supports it. Go's arrays are containers only, so the equivalent is always the explicit loop in the left column — one of several places where Odin's graphics-programming origins show.

That reversal is the trap, not the semantics. It bites on strings, slices, and maps alike, and the compiler will not always catch it because both are often integers.

This is the single most common mistake a Go programmer makes in their first Odin program. Procedures that return a view into existing memory — slicing, strings.trim_space, strings.split_iterator — allocate nothing and must not be deleted, so the return documentation is worth reading.

strings.to_string returns a view into the builder's buffer rather than a copy, so it is valid only until the builder is destroyed. Copy it with strings.clone if it must outlive the builder.

Odin's plain %v already prints field names for a struct, so you rarely need the verbose form at all.

That removes the aliasing surprise where a Go append either mutates the backing array in place or silently reallocates depending on spare capacity. A []T in Odin never reallocates behind your back.

So there is no numbers = append(numbers, …) dance and no way to forget it. It does need delete, and numbers[:] produces a view for any procedure written against []int.

That is the opposite of Go, where delete(m, k) removes one entry and nothing frees the map. slice.map_keys allocates the key slice, so it needs its own delete too.

Note also that slice.linear_search returns an index and a found flag rather than Go's -1 sentinel.

That is the lookup table Go programmers usually build as a map[Fruit]int, but with no hashing and no allocation — and adding a fourth Fruit resizes it automatically rather than leaving a gap.

There is no ++ or -- operator — index += 1 is the only form.

Odin adds ranges ('C' ..= 'F'), which Go has no syntax for at all.

Go's iota constants are just integers, so nothing about them is a closed set — a switch can miss a case and the compiler is content. Adding a fifth Direction in Odin turns every incomplete switch into an error pointing at the exact line, instead of a silent behavior change you find in production.

One difference worth knowing: Odin defers to the end of the enclosing scope, not the enclosing procedure, so a defer inside a loop body runs on every iteration.

Only the spelling changes: proc for func, and -> introducing the results.

The payoff is that when reading a procedure body you know a parameter still holds what the caller passed.

This removes the two workarounds Go programmers reach for constantly: the options struct and the variadic ...Option functional-options pattern. It also makes a call with several boolean flags readable without a comment explaining which true is which.

Closures are so routine in Go that their absence is the most disorienting thing on this page. A procedure value is a bare code pointer with no environment and no hidden allocation — which is precisely why the language omits them, since a capturing closure has to allocate somewhere. The struct is what the Go closure was doing anyway, just visibly.

Only the punctuation moves: Odin writes ..int in the signature and ..numbers as a prefix at the call site, where Go writes ...int and a numbers... suffix.

Because the members are listed explicitly there is no hidden overload set to search and no surprise about which one a call resolves to. It is a middle ground between Go's "one name, one function" and C++-style overloading.

Two Go conveniences do survive: field access auto-dereferences a pointer, and you still choose value or pointer by what the procedure needs to do. What is lost is method-set-based abstraction — which the interfaces section covers.

That naming is the improvement: two embedded fields of the same type do not collide, where Go addresses them by type name. Since Odin has no methods, only fields are promoted, never behavior.

Go struct tags are strings interpreted at runtime by a reflection-based library. This is the difference between describing a wire format to a JSON decoder and actually being the wire format — the latter is what you need when matching a C header or a binary file.

Comparison with == works the same way in both, when every field is comparable. Go requires either all positional fields or the Field: form throughout.

This is the largest conceptual gap on the page, so it gets three rows: the union here, an explicit vtable next, and any after. For a closed set the union is arguably better anyway — no boxing, values inline, dispatch as a jump table, and adding a variant surfaces every site that must handle it. What you give up is Go's open extension: a third party cannot add a Shape without editing this union.

This is exactly what Go's runtime constructs behind an interface value — the difference is that here it is visible, so you can see the indirect call and the type erasure rather than inferring them. Odin's own Allocator and Logger are built this way, which is why the allocator is swappable at all.

The critical difference is lifetime: any points at the original value rather than boxing a copy, so storing one beyond the lifetime of what it references is a dangling pointer. Treat any as a parameter type for the duration of a call — which is how fmt uses it — not as something to keep in a struct.

This is where the absence of interfaces reads as a simplification rather than a loss: Go's sort.Interface needs a named slice type and three methods to do the same job.

Go's iota constants are integers, which is why printing one needs a String() method (usually generated by stringer) and why Direction(99) is a valid value there and has no Odin equivalent.

The Go column shows the standard workaround — an unexported marker method — which still gives you no exhaustiveness check. The nil state means "no event yet" is representable without a separate pointer or boolean; add #no_nil to require a variant always be set.

Go's 1 << iota bitmask is a convention over a plain integer — the shifts are yours to get right, any integer can be assigned in, and printing means writing a decoder. Pinning the width matters when the layout must match an external format.

The difference is that a Maybe cannot be silently used without unwrapping, whereas ignoring Go's found hands you a zero value indistinguishable from a real one.

That makes it a single integer with no allocation and, critically, a closed set the compiler can check in a switch. What you lose is Go's wrapping chain: %w and errors.Is have no direct equivalent, so context is added by returning a union of error enums or a struct instead.

If one feature justifies this page for a Go programmer, this is it: the three-line if err != nil { return err } block becomes a suffix, and adding a layer to the call chain adds one word rather than a block. It does the same job as Rust's ? while leaving the early return visible in the expression.

Where or_return propagates a failure, or_else substitutes a default. It turns the four-line comma-ok-then-if that Go requires into a single expression.

There is no stack unwinding, so the panic-and-recover-at-a-boundary pattern that Go HTTP servers and parsers lean on has no equivalent. One related compile-time nicety: because os.exit never returns, the compiler rejects any defer that could only run after it, so an unreachable cleanup is an error rather than a leak you find later.

Everything else on this page is syntax; this is the actual change. Saying so in a doc comment is the norm. In practice the next few rows matter more, because arenas and the temp allocator mean most code never writes an individual free at all.

Both languages have a context and they have almost nothing in common — confusing them is the most likely early mistake. Go's carries cancellation and deadlines and must be threaded explicitly through every signature. Swapping in an arena, a pool, or a failing allocator for a whole subsystem is a one-line change no signature has to hear about.

In a program with a natural cycle — a frame, a request, a tick — you call free_all(context.temp_allocator) once at the boundary and every scratch value disappears. This is the closest Odin comes to a garbage collector's convenience, except you choose the collection point and it is O(1).

Go needs no such tool, but it also gives you no equivalent lever: this is scoped to whatever subsystem you install it on, works identically in a release build, and costs nothing when not installed.

For an audio callback, an interrupt handler, or a frame budget, the useful guarantee is not "allocates rarely" but "cannot allocate". Go's GC can be tuned and its pressure reduced, but there is no way to make an accidental allocation a hard error.

Both specialize at compile time and both infer the type argument. Go requires a named constraint such as cmp.Ordered; Odin instantiates the body and reports an error if an operation is unsupported, closer to C++ templates. The cost is that a bad instantiation reports its error inside the procedure body rather than at the call site.

That is strictly more expressive than a Go constraint interface, which can only enumerate types, and it moves the error back to the call site where it belongs.

So doubled returns an array of exactly the length it received, checked at compile time. Go generics parameterize over types only, so the closest equivalent takes a slice and loses the static length.

This is the feature Go programmers will miss most. OS threads are expensive to create, so you pool them rather than spawning thousands. sync.Mutex and sync.Wait_Group map directly onto their Go counterparts, and sync.guard is a scoped lock that saves the defer Unlock. The visible plumbing is what Go's closure capture was hiding.

The CSP style Go is built around does not transfer. This is a genuine trade, not a hidden win: Odin bought a smaller runtime and no scheduler in the binary, and the price is that structured concurrency is something you build rather than something you are given.

The default ordering matches Go's sequential consistency, so the extra control (.Relaxed, .Acquire, .Release) is opt-in rather than something you must reason about immediately.

Go splits platform code across _darwin.go / _linux.go files or //go:build tags, which are comments the toolchain reads before compiling — a typo silently excludes a file. Here a mistake is a compile error, and the untaken branches need not even be valid for that target.

Go has no compile-time execution: a lookup table is either built in init(), paying the cost at startup, or generated by go:generate and checked in. Odin's is not the arbitrary compile-time interpreter Zig's comptime provides, but it removes most of what go:generate exists to do.

A hot loop touching one field then reads packed memory instead of striding past the others, and the change is one keyword rather than a new type and a rewrite of every access site. Go cannot express this at all — nor can C, Rust, or Zig without a macro. It is the clearest single reason Odin exists.