Elixir.CodeCompared.To/Go

There is no script mode. elixir script.exs has no counterpart — a Go program is compiled to a single static binary by go build, and go run file.go merely hides the compile step. That binary carries no runtime to install: the whole reason teams reach for Go is that deployment is copy one file, where a release still ships the BEAM.

This is the trade the whole page turns on. You give up the freedom to write anything and have it mean something at runtime; you get back a compiler that rejects a whole category of crash before the code ships. Note the second half of the bargain: Go has no implicit conversion anywhere — not even int to float64 — so strconv.Atoi returns an error alongside its value, and you handle it.

Immutability stops being the physics of the language and becomes a discipline you maintain. := declares-and-infers inside a function; const is compile-time only (no const maps or slices exist). The compiler does enforce one useful habit Elixir never needed: an unused local variable is a compile error, not a warning.

Printf does not add a newline (that is what the explicit \n is for); Println does, and inserts spaces between its arguments. The verb worth memorizing first is %v — the default representation of any value, and %+v adds struct field names, making it the working equivalent of IO.inspect/1. Go's go vet checks that your verbs match your arguments, so a mismatch is usually caught before it prints garbage.

Every Go type has a zero value and variables are always initialized to it: 0 for numbers, "" for strings, false for bools, nil for pointers, slices, maps, channels, and interfaces. That is why "was it set?" so often needs a second return value or a pointer — the value alone cannot tell you apart from a legitimate 0. There is no || fallback and no ternary; write the if.

Nothing here asserts a shape. %{name: name} = person would raise a MatchError the moment person stopped having that key; config.Name cannot fail, because the compiler already proved the field exists. You trade a runtime assertion for a compile-time guarantee — but you also lose the ability to say "this must look like this" in one line.

Notice what the last line costs you. In Elixir an unmatched shape raises FunctionClauseError immediately, at the boundary, with the offending argument in the message; here it returns 0 and the bug surfaces three layers away. Go's switch has no exhaustiveness check, so a new Kind compiles fine and silently falls through. Modeling this with an interface instead (see the Interfaces section) is the idiomatic fix — that is checked.

The shape survives the translation almost intact, and Go's cases are freer than guards — any expression is allowed, including function calls, where Elixir restricts guards to a fixed safe set. What is lost is the binding: a guard sits on a head that has already destructured its argument, so the branch and the extraction happen together. Here they are two separate steps.

The gain is real: Status is a distinct type, so passing an int where a Status belongs will not compile, and a typo cannot invent a new value the way :runnning silently can. The losses are equally real — the value is an integer at runtime, so printing it needs that hand-written String() method, and the switch is still not checked for exhaustiveness (the exhaustive linter exists precisely because the compiler will not do it).

Two things are worse and one is better. Worse: the two values are independent, so nothing stops you reading number when err is non-nil — a tagged tuple makes that unrepresentable — and every failing path must still return something for the value slot, hence the 0. Better: error is an interface, not a bare atom or string, so an error can carry structured data and be inspected without parsing text. And err stays spelled that way — it is as fixed a convention in Go as _from is in a handle_call.

What with gave you — one happy path, one else for every failure — has to be rebuilt by hand, and the temptation to write a bare if err != nil { return err } everywhere loses exactly the context with/else let you add centrally. The counterweight is %w: it wraps the original error inside the new one, building a chain that errors.Is and errors.As can walk later, which is closer to an Elixir exception's stacktrace than to a flat {:error, reason}.

Use errors.Is when you are comparing against a known sentinel value (errors.Is(err, os.ErrNotExist)) and errors.As when you need the concrete type's fields, as here. Both walk the %w chain, so a wrapped error five layers deep is still identifiable — which is what makes returning errors up a call stack survivable without the stacktrace an Elixir exception would have carried for free.

The named return value (message string) is not decoration — it is the only way the deferred closure can change what the function returns, because by the time recover runs the return statement is already past. Reaching for this pattern to emulate rescue is considered a code smell in Go: a library that panics across its own API boundary is a library with a bug. And it does not compose the way rescue does — see the concurrency section for the part that really matters.

Where try/after is a construct you reach for occasionally, defer is everywhere in real Go — it is how files, locks, connections, and transactions are released, written on the line immediately after acquisition so the pairing is impossible to miss. It also fires when the function panics, which is what makes the recover idiom above work at all.

Elixir made "who else can see this change?" an unaskable question. In Go it is a question you must ask on every assignment and every function call, because slices, maps, and channels all pass a reference while structs and arrays copy. Slicing is where the subtlest Go bugs live: original[1:3] is a window onto the same array, and append may or may not reallocate depending on capacity, so whether a write shows through is not stable across inputs.

The %{map | key: value} form also asserted the key already exists; nothing here does — older["typo"] = 1 silently adds a key. maps.Clone (Go 1.21+) gives the copy semantics you are used to, but it is a shallow copy and, crucially, you have to remember to ask for it. This is the habit that costs Elixir developers the most: passing a map into a function no longer guarantees it comes back unchanged.

The Elixir habit of returning a new state from every function still works in Go and is often the better design — but it is now a choice with a cost, since a large struct really is copied. Pointers here are far tamer than C's: no arithmetic, no manual free, and the garbage collector keeps whatever is still reachable, so &counter on a local is perfectly safe and the value simply escapes to the heap.

The range form yields index and value, which is why the _ is there — forgetting it is the classic first-week bug, since for number := range numbers silently iterates the indices. The loop is also a single pass where the pipeline was three, and it allocates nothing. Go's position is that without lightweight lambda syntax a chain would not actually read better; whether you agree, this is what every Go codebase looks like, so consistency is on its side.

Go randomizes map iteration order on purpose, varying it run to run so no code can accidentally depend on it — stricter than Elixir's maps, whose small-map ordering is merely unspecified. So "print these sorted" means collecting the keys and sorting them yourself, and there is no Map.keys/1. Note also that delete, len, and append are built-in functions, not methods: there is no Map module to reach into.

In place means the caller's slice is reordered — there is no sorted and people side by side afterward, only people. slices also gives you Contains, Index, IndexFunc, Reverse, Max, and Min, which covers a useful slice of Enum; what it deliberately does not give you is Map or Filter.

That signature has a name in the standard library — iter.Seq[int], with iter.Seq2 for key/value pairs — and the func(func(int) bool) written out above is exactly what it aliases. The laziness is genuine, so an infinite generator is safe. What is missing is composition: there is no Stream.map to stack on top, so combinators over iterators are something you write or import.

That copy is doing the work %{person | age: 37} did, but by different physics: Elixir shares structure and forbids mutation, Go duplicates the bytes and permits it. There are no field defaults — Person{} gives "" and 0, and a constructor function (NewPerson) is the conventional way to supply anything else. There is also no __struct__ key and no runtime reflection needed to know the type: it is in the static type.

This is not objects returning: there is no inheritance, no super, and no class — just functions with a receiver, which the compiler dispatches statically. The one thing to watch is mixing receiver kinds on the same type, since Scale's pointer receiver means only an addressable value can call it, and only the pointer type satisfies an interface that includes it. Pick one style per type and stay with it.

Promotion is shallow and resolved at compile time by name: an Article.Describe of its own simply shadows the embedded one, with no super to call and no runtime lookup. The honest comparison is to defdelegate and to use's __using__ injection — Go generates nothing and rewrites nothing, so what you can reach is exactly what the two type definitions say.

Satisfaction is structural and checked where the value is used, so you can define an interface describing a type you did not write and did not import — something defimpl can also do, but only by naming the protocol. The Go convention is to keep interfaces tiny (one or two methods) and declare them in the consumer package rather than beside the implementation, which inverts where the coupling lives. The cost is discoverability: nothing in Number says it implements anything.

Inside each case, typed has that concrete type, so the compiler still checks the body — the binding is the whole point. But reaching for any throws away the static guarantees the rest of the page was buying, and idiomatic Go treats it as a last resort: prefer an interface with a method, or generics, and keep the type switch for genuinely heterogeneous input like decoded JSON. The single-type form value.(int) exists too, and its comma-ok variant is how you avoid a panic on a wrong guess.

A @behaviour needs the implementing module to name it and needs a @callback spec to exist at all; MemoryStore names nothing. In exchange, dependency injection stops being a runtime module attribute or an application-config swap and becomes an ordinary parameter with a type the compiler enforces — which is also how test doubles work in Go: define the interface next to the consumer, pass a fake in the test.

Strings are immutable in both languages, so these all return new values. Two habits to drop: there is no ? suffix convention (Contains, not contains?), and Replace takes a count — ReplaceAll is the one matching String.replace/3's default. And unlike the sigil-rich Elixir side, Go has no ~s, no ~w, and no heredoc: a backtick-quoted raw string is the only alternative literal.

Note the asymmetry that catches everyone: text[1] gives you a single byte (a byte, alias for uint8), while ranging over the same string decodes runes and reports the byte offset of each. Go stops at code points and has nothing like String.graphemes/1, so a combining accent or an emoji with a skin-tone modifier counts as several runes — grapheme clustering lives in golang.org/x/text, outside the standard library.

A Builder is an io.Writer, which is why fmt.Fprintf can write straight into it — that one small interface is the join point for files, network connections, HTTP responses, and buffers alike, and learning it early pays for itself. For joining a slice with a separator, strings.Join(parts, ", ") is the direct Enum.join/2 and is what you would actually reach for here.

Go's functions do take their subject first, so the data-first shape the pipe depends on is already there — only the operator is missing, and proposals to add one have been consistently declined. Method chaining does work on types you define, by returning the receiver, so a fluent builder is possible; it is simply not how the standard library is written.

There is no capture operator (&String.upcase/1) and no shorthand (&(&1 * 2)) — functions are values, so you pass strings.ToUpper by name, and everything else is a full func literal. That verbosity is exactly why Go declined to add map/filter. The capture-by-reference rule is also what makes the goroutine examples in the next section work at all — and what makes them need a mutex.

So the Enum.map you missed two sections ago is writable — it is simply not in the standard library, because the community has not settled on one signature. Constraints go where any is: comparable permits ==, and an interface with a type set like ~int | ~float64 permits arithmetic. Generics have real limits, though — no generic methods (only functions), and no way to make a type parameter's fields accessible.

There is no pid, so there is no Process.monitor, no Process.link, no Process.exit, and no registry to look one up by name. Everything OTP gives you for addressing and observing a process becomes a channel you passed in beforehand, or a context you threaded through. The upside is that goroutines are even cheaper than processes — a few kilobytes of growable stack — because they skip the isolation entirely, which is what the rest of this section is about.

Nothing forces you to write those Lock/Unlock lines — the program compiles, usually produces the right answer, and corrupts the count under load. go build -race exists precisely because this class of bug is invisible otherwise, and running your tests under it is not optional in a Go codebase. One thing did get better: since Go 1.22 each iteration gets a fresh index, so the notorious "all goroutines see the last value" bug is gone.

The Elixir cell plucks the urgent message past an earlier one; no channel can express that. Rebuilding priority means a separate channel per class of message plus a select that checks the urgent one first, and you own the starvation risk that creates. Two more differences worth internalizing: a channel is typed, so one channel carries one shape of message where a mailbox carries anything; and an unbuffered channel blocks the sender until a receiver is ready, where send/2 never blocks.

If several cases are ready, select picks one at random — deliberately, to prevent starvation — where receive takes the clauses in order. A default case makes the whole thing non-blocking, which is the "peek without waiting" that receive … after 0 gives you. And select is genuinely more capable in one direction: it can wait to send as well as receive, something a mailbox has no concept of.

Because count never leaves that goroutine, no mutex is needed — the isolation is a convention you maintained rather than a property of the runtime. Everything else GenServer hands you is now yours to write: no name registration, no handle_info, no terminate, no timeouts on a call, no :sys introspection, no hot code reload, and no supervisor. For shared state that is only read and written, most Go code skips all of this and reaches for a sync.Mutex instead.

There is no isolation boundary, so there is nothing for a supervisor to supervise — which is why Go has no supervision trees and why "let it crash" is not a strategy you can port. Note too that even the recover above only stops the bleeding: the goroutine is finished, its work is lost, and nothing restarts it from a known-good state. The equivalent resilience is usually bought outside the program, by a process manager or an orchestrator that restarts the whole binary.

A Context carries a deadline and a cancel signal down a call tree, so canceling a parent cancels every child that was threaded it — genuinely useful, and the reason ctx is the first parameter of nearly every Go library function. But notice the direction: context lets a parent tell a child to stop, while a monitor lets a parent learn that a child died, and why. Go has no equivalent of that second message — a goroutine's death is not observable at all — so nothing restarts, nothing is linked, and a goroutine that ignores ctx.Done() simply keeps running. Restart-on-failure has no in-language answer; it lives in your main, in a library, or in Kubernetes.

There is no Hex — a dependency is a URL, resolved straight from its repository, and the version is a git tag. Minimal version selection is the deep difference: Go picks the lowest version satisfying every requirement, so builds are reproducible without a lock file doing the work mix.lock does (go.sum records hashes only). Tasks have no home either: mix custom tasks become ordinary programs, a Makefile, or go generate.

There is no assert macro and no assertion library in the standard library — you write the comparison and call t.Errorf yourself, so nothing rewrites your expression to produce a pretty failure the way ExUnit's macro does. What you get instead is built in and free: go test needs no dependency, table-driven subtests with t.Run are the community standard, benchmarks and fuzzing share the same file, and t.Parallel() is the async: true you already use.