C++.CodeCompared.To/Go

Every Go file names its package on the first line, and main is the one that produces an executable. The import is not a textual include but a real dependency on a package — and if you imported fmt without using it, the build would fail, not warn. That is a running theme: Go turns things other languages warn about into hard errors, on the reasoning that a warning nobody fixes is a warning nobody reads. Tabs are the standard indentation because gofmt emits them, which is the subject of the next row.

The mechanism is worth understanding because it explains several later omissions. Since an importing package reads only a compact summary of its dependency's API, compilation cost does not compound the way it does when every #include pastes a header into every translation unit. Forbidden import cycles keep the graph acyclic and therefore parallelizable. And it is not free: this model is part of why Go went a decade without generics, since a summary must describe everything an importer might instantiate. Fast builds bought a smaller language, and whether that trade is worth it is the argument you are actually evaluating.

The absence of configuration is the entire feature: clang-format is more capable and therefore something a team must agree about, while gofmt gives everyone the same answer whether they like it or not. The knock-on effect is that all Go code you will ever read looks the same, so unfamiliar code is easier to skim. Related tools follow the same philosophy — go vet for likely mistakes, go test for tests, go doc for documentation — all in the toolchain, none to choose.

The rule is uniform: numbers are 0, strings are "", pointers, slices, maps, channels and interfaces are nil, and a struct is all of its fields zeroed recursively. That eliminates the uninitialized-read bug entirely, and it shapes API design in a way worth noticing — a type is usually built so its zero value is useful, which is why var buffer bytes.Buffer and var lock sync.Mutex are ready to use with no constructor call. A nil slice is not a null pointer crash: len is 0 and append works.

C declaration syntax was designed so a declaration mirrors the expression that uses the variable, which is elegant and unreadable past two levels — hence the "spiral rule" and cdecl.org. Go puts the name first and the type after, read outermost-in, so no tool is needed. Two other things here: := declares and infers in one step and works only inside a function, and _ is the blank identifier, which is how you discard a value — needed because an unused variable is a compile error, not a warning.

Go performs no implicit conversion between numeric types — not signed to unsigned, not int32 to int64, not even int to float64. Every one is written out, which is noisier and makes the sign-comparison trap impossible. The exception that keeps it bearable is untyped constants: a literal like 3 has no type until it is used, so var ratio float64 = 3 works while assigning a typed int variable would not. Note also that int and int32 are distinct types even when they are the same width.

Go has no stack/heap distinction in the source: you write &point and the compiler performs escape analysis to decide where the object actually lives. If the pointer never leaves the function, it stays on the stack and costs nothing; if it escapes, it is heap-allocated and the garbage collector owns it. So new versus stack allocation is not a decision you make, and returning a pointer to a local — undefined behavior in C++ — is idiomatic Go. You can see what the compiler decided with go build -gcflags=-m, which is the tool to reach for when allocation shows up in a profile.

A C++ destructor belongs to the type, so the author of Transaction guarantees cleanup and every user gets it for free. A defer belongs to the call site, so every caller must remember to write it — the compiler will not. In exchange it is simpler and more flexible: deferred calls run in LIFO order at function exit including on panic, and their arguments are evaluated immediately while the call itself waits. The idiom is to defer on the line after acquiring, so file, err := os.Open(…) is followed immediately by defer file.Close().

Pauses are typically well under a millisecond and largely independent of heap size, because marking runs concurrently with the program. What you pay is throughput — the collector uses real CPU, and write barriers cost something on every pointer store — plus the fact that memory is released later than a C++ program would release it. For a C++ programmer the practical adjustments are: allocation rate is what to optimize (not allocation count at a single site), GOGC trades memory for CPU, and the honest answer for hard real-time or a fixed memory budget is still C++. Note for index := range 3, the range-over-integer form added in Go 1.22.

Immutability means passing a string is always cheap (two words) and always safe, with no copy and no aliasing question. len counts bytes exactly as size() does, and indexing yields a byte. Building a string with += in a loop is O(n²) since each step allocates, so the idiom is strings.Builder — the direct analogue of reserving capacity on a std::string. Converting to []byte copies, precisely because the string cannot be allowed to change underneath.

Two indexing modes coexist and confusing them is the classic Go string bug: greeting[2] gives a single byte, while range decodes and yields runes with their byte offsets — notice the indexes jump from 2 to 4 across the two-byte ï. A rune is just an alias for int32 holding a code point. Unlike Rust, Go does not guarantee a string is valid UTF-8; invalid bytes decode to the replacement character rather than being rejected, which is more forgiving and less safe.

The three-word header — pointer, length, capacity — means a slice both views a backing array and keeps it alive, so unlike a std::span it can never dangle. The cost is that sharing is the default: window[0] = 99 changes readings too, which is the behavior to watch for when passing slices around. append writes into spare capacity when there is some and allocates a fresh array when there is not, so whether it aliases the original depends on capacity — which is why append's result must always be assigned back.

Whether append shares the backing array with the slice you appended to depends on whether there was spare capacity — so the same line aliases or does not depending on runtime state. The first case above silently overwrites readings[2]; the second reallocates and leaves the original alone. Two habits defuse it: always assign the result (slice = append(slice, …)), and when you need a guaranteed-independent copy, say so with slices.Clone or a three-index slice (readings[0:2:2]) that caps capacity at the length.

The two-value form — the "comma ok" idiom — is how you tell a stored zero from an absent key, and it appears in three other places in Go (type assertions, channel receives, and the same on any map read). Note also that iteration order is deliberately randomized: Go shuffles it on every run specifically to stop code depending on an order the implementation never promised, which is the opposite of Python's guarantee and stricter than std::unordered_map, whose order is merely unspecified rather than actively varied. Sort the keys when you need determinism.

All four shapes are spellings of the same keyword: three clauses, a condition alone (the while), nothing at all (an infinite loop), and range. The range form always yields two values — index and element for a slice, key and value for a map — so the _ discarding the index above is extremely common. One genuine difference from C++: ++ is a statement, not an expression, so x = y++ does not compile and there is no prefix form. Braces are mandatory even for one-line bodies.

The missing break bug is gone, and grouping cases is a comma-separated list rather than stacked empty labels. Two capabilities C++ lacks: a switch can test any comparable type including strings, and a subject-less switch takes boolean cases, which is the idiomatic replacement for a long if/else if ladder. What Go does not have is exhaustiveness checking — a missing case is silently nothing, exactly as in C++, so the linter exhaustive exists to fill the gap.

Because a function can return a result and a status without wrapping them, Go never needed exceptions, std::optional or an out-parameter convention — value, err := doSomething() is the whole mechanism, and the errors section below is just this row applied. Note the parameter list (numerator, denominator int), where consecutive parameters sharing a type name it once. Return values can also be named, which documents them and lets a bare return send the current values.

Go's stated reason for rejecting overloading is that it complicates the reader's job more than it helps the writer's — resolving which function a call means should not require type deduction. Default arguments went for the same reason. The options-struct pattern above compensates, and it works precisely because every field has a well-defined zero value, so ConnectOptions{} is a meaningful "all defaults". The other common spelling is functional options (connect(host, WithPort(443))), which reads better in libraries and costs a closure per option.

The variable itself is captured, so a closure sees later changes and can outlive the enclosing function safely, since escape analysis moves the variable to the heap. The classic trap was a loop variable shared by every closure created in the loop; Go 1.22 changed loop variables to be per-iteration, which fixed it, so older advice about copying the variable into the loop body is now obsolete. When you genuinely want a snapshot rather than a reference, assign to a new variable inside the closure or pass it as a parameter.

A value receiver gets a copy, so it cannot mutate the original — but this is a convention, not a guarantee like const, since the copy may still contain pointers to shared data. Go takes the address automatically when you call a pointer method on an addressable value, so counter.Increment(5) works without &. The style rule is to be consistent per type: if any method needs a pointer receiver, give them all pointer receivers, because a mixed set makes the method set confusing when the type is used through an interface.

An embedded field has no name, and its fields and methods are promoted to the outer type, so derived.Describe() works. What does not happen is subtyping: a Derived is not a Base, cannot be assigned to one, and there is no virtual dispatch — Base.Describe calling another method gets Base's, never an override, so the template-method pattern does not work. Polymorphism in Go comes from interfaces (next section), not from embedding. The embedded value is still reachable by type name, which is how you disambiguate when two embedded types promote the same name.

Because satisfaction is structural rather than declared, the consumer defines the interface it needs, not the producer. That means you can write a one-method interface describing exactly what your function uses and pass it a type from a third-party library that has never heard of you — no adapter, no wrapper, no modification. It also inverts the usual advice: Go interfaces should be small (io.Reader has one method) and defined next to the code that consumes them. The cost is that satisfaction is accidental, so a renamed method silently stops satisfying an interface somewhere else.

A type switch is dynamic_cast's job with dedicated syntax, and there is no equivalent of -fno-rtti — an interface value always carries its dynamic type, so this always works. The single-type form uses the comma-ok idiom again; without the second variable, a failed assertion panics rather than yielding null, which is the trap. Go's culture treats heavy type-switching as a smell, the same way C++ treats a chain of dynamic_casts: if you are branching on concrete types, the interface probably wants another method.

An interface value is a pair: a dynamic type and a value. It is nil only when both halves are nil. Returning a nil *ProblemError as an error fills in the type half, so the result compares unequal to nil while carrying nothing — and every if err != nil in the caller fires on a success path. The fix is a rule rather than a check: never declare a variable of concrete error type and return it as error. Return a literal nil on the success path, and construct the concrete error only where you actually return one.

A constraint is an interface used as a bound, so cmp.Ordered names the types supporting <, and the body is checked once against it — the error points at your definition rather than unrolling into a library. What Go does not have: no specialization, no non-type parameters (so no std::array<int, 3>), no variadic type parameters, no metaprogramming, and no generic methods — a method cannot introduce a type parameter of its own. Implementation is a hybrid of monomorphization and dictionary passing, so performance sits between a template and a virtual call. Templates are a compile-time programming language; Go's generics are strictly a way to avoid writing the same function twice.

error is an ordinary interface with one method, so errors are values you return, inspect and wrap like anything else. The case for it is that every place a function can fail is visible in the source and in the signature, so there are no invisible early exits and no exception-safety analysis. The case against is that if err != nil { return nil, err } is perhaps a fifth of the lines in a real Go program, and several proposals to shorten it have all been rejected. %w wraps an error so errors.Is and errors.As can inspect the chain — the equivalent of catching a specific exception type.

A panic signals a bug — an index out of range, a nil dereference, an impossible state — and the intended response is to fix it, not to catch it. recover exists mainly so a server can stop one request's panic from killing the process, and so a package can convert an internal panic into an ordinary error at its public boundary. It only works inside a deferred function, which is why the closure above looks the way it does. If you find yourself panicking to report an expected condition, you are fighting the language; return an error instead.

A goroutine starts with a small growable stack and is multiplexed onto OS threads by Go's own scheduler, so creating one costs roughly a function call and blocking one costs nothing — the scheduler simply runs another. That is why the idiomatic Go server is one goroutine per connection, a design that is untenable with std::thread and which C++ reaches for coroutines and executors to approximate. sync.WaitGroup is the join: Add before launching, Done when finished, Wait to block. Note that goroutines are not awaited by default — main returning kills them all.

A channel is a typed, synchronized queue built into the language, replacing the mutex-plus-condition-variable-plus-queue assembly on the left. An unbuffered channel is a rendezvous: the send blocks until a receiver takes it, which synchronizes the two goroutines as a side effect. close signals completion and makes range terminate — and the rule is that only the sender closes, since sending on a closed channel panics. Go still has sync.Mutex and it is the right tool for guarding a small piece of shared state; channels are for handing ownership of data from one goroutine to another.

That primitive is what makes timeouts, cancellation and fan-in expressible without a state machine — a select with a time.After case is a timeout, and a default case makes the whole thing non-blocking. context.Context is the convention built on top: it carries a cancellation signal (and a deadline, and request-scoped values) down a call tree, and by convention it is the first parameter of any function that may block. Every standard-library call that does I/O accepts one, so cancellation propagates through code you did not write — which is the part C++ has no answer for.

The race detector is part of the toolchain rather than a separate build mode you have to discover: add -race to go test or go run and any conflicting unsynchronized access is reported with both stack traces, even when the run produced the right answer. It is dynamic, so it only sees races on code paths actually executed — running your test suite with -race in continuous integration is the standard practice. ThreadSanitizer does the same job for C++ and is the same technology; the difference is that in Go it is one flag everyone already knows about.

Two design choices are worth knowing. Import paths are URLs, so publishing a package means pushing to a repository and there is no registry to be compromised, rate-limited, or name-squatted. And minimal version selection picks the lowest version satisfying all requirements rather than the newest allowed — the opposite of npm and Cargo — so adding a dependency cannot silently upgrade an unrelated one, and a build is reproducible without a lockfile ritual. go.sum records hashes, and the checksum database makes tampering detectable.

Docker, Kubernetes, Terraform, Prometheus and most of that generation are Go programs, and single-binary deployment is a large part of why. Cross-compilation needs no toolchain to install because the compiler is not a wrapper around a system linker for the common cases. The costs are honest ones: binaries start around 2MB because the runtime is included, and linking against C libraries via cgo gives up static linking, cheap cross-compilation and some performance all at once — which is why idiomatic Go libraries go to real effort to be pure Go.

You cannot express "this parameter is read-only" for a slice, map, pointer or any type with reference semantics. The compensations are partial: passing a struct by value copies it, so a value receiver is a genuine read-only view of the top level, and an interface exposing only reader methods hides the mutating ones. Neither is enforcement — a caller can always type-assert back. For a C++ programmer used to const as a design tool this is a real loss, and Go's position is that const-correctness costs more in complexity than it returns in guarantees. Judge that for yourself; it is one of the sharper disagreements between the two languages.

The reasoning is the same as for overloading generally: a + b should not require knowing the types to know what happens, and should never allocate or block behind your back. The practical cost lands on anything matrix- or big-number-shaped, where a.Add(b).Mul(c) is genuinely worse than a + b * c — math/big is the standard library living with it. One thing you do get free: == is defined structurally for any struct whose fields are all comparable, so no operator== is needed. Structs containing slices, maps or functions are not comparable and using == on them is a compile error.

The reasoning is that a warning nobody is forced to fix accumulates until the build is noisy enough that nobody reads any of it — so Go has essentially no warnings, only errors. In practice it means dead imports and leftover variables never build up, and the diff for deleting code is always complete. It is genuinely annoying while debugging, when commenting out one line orphans a variable; the escape hatches are _ = value and, for imports, _ "package" which imports purely for side effects. Note that unused function parameters and package-level variables are fine — the rule is local variables and imports only.

Go is a smaller language than C++ by a very wide margin, and nearly every omission above was argued for rather than merely unimplemented. The question is not which list is longer but which one describes your bottleneck. If your pain is build times, onboarding, dependency management, deployment, and getting concurrency right, Go addresses all five directly. If your pain is the last factor of two in throughput, a fixed memory ceiling, deterministic latency, or expressing invariants in the type system, Go removes tools you rely on and gives back things you already have. Most teams that move are in the first group; most teams that regret it were in the second.