Kotlin.CodeCompared.To/Go

Go asks for more ceremony up front: every file declares its package, executables live in package main, and even printing needs the fmt import. There are no top-level statements and no REPL-style script mode — and gofmt (tabs, brace placement, everything) is not a suggestion but the single mechanical style every Go codebase shares.

The loss of val stings: Go has no way to declare an immutable local (its const covers only compile-time numbers, strings, and booleans). In exchange Go enforces something Kotlin only warns about: an unused variable is a compile error, which is why quick experiments end up assigning to _.

The zero value is a design pillar, not a default: 0, "", false, and nil are meant to be immediately useful (a zero sync.Mutex is an unlocked mutex; a nil slice appends fine). Well-designed Go types advertise "the zero value is ready to use." The dark side is the nil section below — reference types zero to nil, and nothing like Kotlin's T? tracks it.

No tuple object exists — the values come back as two real assignments, no allocation, no componentN(). Note the parameter shorthand too: numerator, denominator int declares both as int, with the type written once, after the names (Go reverses Kotlin's name: Type order throughout).

Go's anonymous functions are full closures — scale captures multiplier exactly as Kotlin's lambda does — but there is no shorthand: no it, no expression body, no trailing-lambda syntax. func(number int) int { return … } is as terse as it gets, which previews the collections section: without light lambda syntax, map/filter chains never became idiomatic Go.

The idiomatic substitute is an options struct: struct literals support field names (GreetOptions{Punctuation: "?"}), omitted fields take their zero values, and the function fills defaults in — Kotlin's named-and-defaulted parameters rebuilt from plainer parts. The verbosity is real and accepted; Go bets that call sites reading identically everywhere beats concision.

This is the adjustment Kotlin developers feel hourly at first. Go's if does offer one thing Kotlin's lacks — an init statement scoped to the condition, if value, ok := lookup(key); ok { … } — which the nil and error sections lean on constantly.

Go's conditionless switch is Kotlin's subjectless when almost line for line, and like when it never falls through (no break needed; an explicit fallthrough keyword exists for the rare opposite wish). The differences: switch is a statement, so each arm returns rather than the whole construct producing a value, and nothing enforces exhaustiveness — default is optional and missing cases are silent.

for condition { } is the while loop, for { } alone loops forever, and for index, value := range collection is Kotlin's withIndex() built in (drop the index with _, or the value entirely). One keyword, four shapes — a fair summary of Go's whole design.

Absence is modeled with a pointer (*string), and the if name != nil check is on you, every time, with no smart cast confirming you did it. Forgetting is a runtime nil pointer dereference panic — precisely the billion-dollar mistake Kotlin's type system closed. Idiomatic Go often sidesteps pointers-for-absence using the comma-ok pattern next, or multiple returns with an error.

A missing key hands back the value type's zero value plus ok == false — no null, no Option, just two returns and a convention strong enough that "comma-ok" is the pattern's actual name. The if-with-init form keeps found scoped to the check, which is as close as Go gets to ?.let { }.

An error is an ordinary value (any type with an Error() string method), returned last by convention and checked immediately. There is no unwinding, no invisible control flow, and no forgetting quietly — ignoring the return is at least visible in the code. The cost is repetition Kotlin never asks for; the benefit is that every failure path is written down where it happens.

The %w verb wraps a cause the way exception chaining does, and errors.Is/errors.As walk the chain the way catch matches exception types. Declared sentinel errors (var errDiskUnreadable = …) play the role of Kotlin's exception classes: stable identities code can test against.

A panic unwinds the goroutine running deferred functions, and an unrecovered panic kills the program — like an uncaught exception, but the culture treats reaching for it as failure: expected problems travel as error values. recover exists (inside a defer) mainly so libraries can convert an internal panic into an error at their public boundary.

Structs are plain value types: == compares field by field out of the box (for comparable fields), %+v prints fields with names, and assignment copies the whole struct — closer to a Kotlin data class's copy() on every assignment than to JVM reference semantics. The capitalized field names are not a style choice, as the next concepts explain.

The receiver — (counter *Counter) — is Kotlin's implicit this made explicit and named. The star matters: a pointer receiver mutates the caller's struct, a value receiver gets a copy (an Increment on a value receiver would count into the void — a legendary Go beginner bug Kotlin's reference semantics never exposed you to). Convention: if any method needs a pointer, give them all pointers.

Two levels only — exported or package-local — where Kotlin offers four. It reads oddly for a week, then becomes information: every call site shows you what crosses a package boundary (fmt.Println, account.BalanceFormatted()) without a jump to the declaration. This is also why earlier examples capitalized struct fields: fmt could not print unexported ones from another package.

Embedding looks like inheritance — dog.Describe() and even dog.Name resolve through the embedded Animal — but it is delegation without a subtype relationship: a Dog is not assignable where an Animal is expected, there is no override, and no fragile-base-class problem. Polymorphism belongs entirely to interfaces, next section.

Neither Dog nor Robot mentions Speaker — the compiler checks the method set at the point of use. The payoff is decoupling Kotlin cannot express: you can define an interface for a third-party type that has never heard of you, and the type satisfies it retroactively. The cost is discoverability; "what implements this?" needs tooling, not a : Speaker to grep for.

Implementing String() string satisfies fmt.Stringer, and every fmt verb picks it up — no Any base class required, just structural satisfaction of a one-method interface. The design advice that follows is Go's most quoted proverb: "the bigger the interface, the weaker the abstraction." Accept interfaces, return structs, keep both small.

The type switch value.(type) binds typed with the matched case's concrete type in each arm — Kotlin's smart cast, spelled once for the whole ladder. The single-type form is the assertion text, ok := value.(string), comma-ok again. any is a built-in alias for the empty interface interface{}, satisfied by everything — Kotlin's Any, structurally.

numbers = append(numbers, 4) is mandatory, not style: when the backing array is full, append allocates a bigger one and the old slice header still points at the old memory. Slicing with numbers[1:3] is a view sharing the same backing array (mutations show through), unlike subList's wrapper semantics — the sharing is where subtle Go bugs live.

Go map iteration order is deliberately randomized — the runtime varies it run to run so nobody accidentally depends on it, where Kotlin's LinkedHashMap default preserves insertion order. Printing sorted therefore means collecting the keys and sorting them yourself. delete is a built-in function, not a method, like len and append.

The standard library has grown helpers — slices.Contains, slices.SortFunc, slices.IndexFunc, and iterator support since Go 1.23 — but no Map/Filter chain, and the community mostly does not want one: without lightweight lambda syntax the loop is often shorter, always allocation-transparent, and reads identically in every codebase. Expect to miss this for a month; expect to stop noticing after.

slices.SortFunc takes a three-way comparator returning negative/zero/positive — Kotlin's compareBy world rather than its sortedBy key-extractor sugar — and sorts in place, where sortedBy returns a new list. The generic slices package (Go 1.21+) replaced the older reflection-based sort for most uses.

[T cmp.Ordered] is Kotlin's <T : Comparable<T>>; constraints are interfaces (sometimes listing type sets like ~int | ~string). What Go still refuses: variance annotations (out/in have no counterpart), generic methods on types, and any use of generics where an interface would do — the proverb is "write concrete code first." The built-in min/max (Go 1.21+) are themselves generic.

The deep difference is structure. A Kotlin coroutine is born inside a scope that owns it: runBlocking cannot exit until its children finish, and canceling the scope cancels them. A goroutine has no parent — go func() and it is loose in the runtime, with sync.WaitGroup bookkeeping (Add/Done/Wait) standing in for what Kotlin's structured concurrency does automatically. Forgetting Wait means main exits and the workers silently die; there is no compiler or scope to catch it.

Line for line the same program: an unbuffered channel, a producer that closes when done, a consumer that ranges until close. Go's arrow syntax (channel <- to send, <-channel to receive) is dedicated language surface where Kotlin uses methods, and "don't communicate by sharing memory; share memory by communicating" is the Go proverb both APIs encode.

Both selects wait on multiple channel operations and take whichever is ready first (choosing randomly on ties — Go randomizes deliberately, like its map order, to keep programs honest). Kotlin's is an expression returning a value, in character for each language. Go's adds a default arm for non-blocking polls and is bread-and-butter for timeouts via <-time.After(…).

Kotlin's version cannot leak: if one async throws, the scope cancels its siblings and rethrows — lifecycle, cancellation, and error propagation are the scope's job. Go's version works because each goroutine writes a distinct index (safe without locks) and the WaitGroup count is right — both properties you maintain, unchecked. The community's golang.org/x/sync/errgroup reconstructs a scope-like pattern, and Kotlin's designers cite exactly this gap as why coroutines are structured.

The idiom is acquire-then-defer on adjacent lines, so the cleanup is visible at the acquisition site. Differences from use { }: defer is function-scoped, not block-scoped; multiple defers run last-in-first-out; and deferred calls run even during a panic — which is how recover gets its chance. Nothing enforces the pairing, though: forget the defer and the resource leaks silently, where Kotlin's use can't be half-applied.

The verbs to learn first: %s strings, %d integers, %v anything (its "just print it" default), %+v structs with field names, %q quoted, %T the value's type. Sprintf returns the string instead of printing. Unlike Kotlin's compile-checked templates, a wrong verb is only caught by go vet — run it.

Go strings have almost no methods — the operations are package functions taking the string first, so Kotlin's greeting.uppercase() becomes strings.ToUpper(greeting). Strings are immutable UTF-8 byte sequences in both languages; note strings.Replace takes a count (-1 for all), where Kotlin's replace always replaces every occurrence.