The Complete Go (Golang) Guide

• vs C/C++: Go has garbage collection — no manual malloc/free, no use-after-free, no double-free. No pointer arithmetic. No header files. Compiles in seconds, not minutes.
• vs Java/C#: No JVM/CLR — Go compiles to a static native binary. No reflection-heavy frameworks. Startup is <10ms instead of multi-second JVM warmup. Memory footprint is ~10× smaller.
• vs Python/Node.js: Statically typed (catches bugs at compile time), 10–100× faster on CPU work, true parallelism via goroutines (not just async I/O on a single thread).
• vs Rust: Go gives up some peak performance and memory safety guarantees for radical simplicity — no lifetimes, no borrow checker, no traits/generics gymnastics. Faster to learn, faster to ship.
• vs Ruby/PHP: Compiled, not interpreted. Concurrent by default. No "global interpreter lock" issues.

• vs Node.js: Node needs node + npm + tsc + eslint + prettier + jest + nodemon as separate tools, each with its own config file. Go has all of this built into one binary.
• vs Python: Python needs python + pip + venv/poetry + black + pytest + mypy. Go has none of these — no virtualenv ever needed because dependencies are versioned per-module in go.mod.
• vs Java: No JAVA_HOME, no CLASSPATH, no Maven/Gradle, no pom.xml. Just go build.
• vs C/C++: No Makefile, no CMakeLists.txt, no autotools. Builds are reproducible across machines because the toolchain is opinionated about layout.

• Unused imports = compile error. Not a warning, an error.
• Unused local variables = compile error. (Unused package-level vars are allowed.)
• Opening brace MUST be on the same line as func, if, for — never on the next line.
• One package per directory. All .go files in a folder must declare the same package name.
• No semicolons. The lexer inserts them automatically at line ends.

• vs npm: One npm package = one repo with one entry point. One Go module can contain hundreds of packages, each independently importable. The module path doubles as the import URL — there's no central registry like npmjs.com.
• vs Python: Python imports are file-based; Go imports are directory-based. Every .go file in a folder must declare the same package name. No __init__.py required.
• vs Java: No Maven Central, no group/artifact IDs. The import path is the URL where the source lives. Visibility uses case, not public/private keywords.
• vs Rust: Cargo is similar in spirit but uses a registry (crates.io). Go is fully decentralized — any git repo can be a module.

• Uppercase first letter (User, GetName, MaxRetries) = exported, importable from outside the package.
• Lowercase first letter (user, getName, maxRetries) = unexported, only visible within the same package.
• This applies to everything: types, functions, variables, constants, struct fields, methods, even individual struct tags.

• Numeric: int, int8, int16, int32, int64, uint, uint8(=byte), uint16, uint32, uint64, float32, float64, complex64, complex128, uintptr.
• Text: string (immutable bytes), rune (= int32, one Unicode code point).
• Other: bool, error (interface).
• Composite: arrays ([N]T), slices ([]T), maps (map[K]V), channels (chan T), structs, interfaces, function types, pointers (*T).

• vs JavaScript/Python: Types are fixed and checked at compile time. There is no runtime TypeError from passing a string where a number was expected — the code simply won't compile.
• vs C: Integer sizes are defined (int32 is always 32 bits, never platform-dependent). There are no implicit numeric conversions — int + int64 is a compile error; you must write int64(x) + y.
• vs Java: The short form x := 10 means you rarely write the type explicitly. No autoboxing — primitive numerics never become "objects".
• vs TypeScript: Go's types are real (not erased). The same type system runs at compile time and is reflected at runtime via the reflect package.

• := can shadow outer variables if you're not careful — use = to reassign.
• The default int is platform-dependent (32 or 64 bits) — use explicit sizes like int64 when interop matters.
• Floating-point comparisons need an epsilon: math.Abs(a-b) < 1e-9, never a == b.
• nil is typed: a nil *int is not interchangeable with a nil *User.

• Sequential enum: const ( Sunday = iota; Monday; Tuesday; ... ) → 0, 1, 2, ...
• Bit flags: const ( Read = 1 << iota; Write; Execute ) → 1, 2, 4 (powers of two for bitwise OR).
• Skip values: Use _ to skip — const ( _ = iota; KB = 1 << (10 * iota); MB; GB; TB ).
• Custom typed enums: type Status int; const ( Active Status = iota; Inactive; Banned ).

• vs JS const: JavaScript's const only freezes the binding — the underlying object can still mutate. Go constants are truly immutable and can only hold primitive values, not arrays or maps.
• vs Java final: Java final can be assigned at runtime (final long now = System.currentTimeMillis()); Go constants must be computable at compile time. const x = time.Now() will not compile.
• vs C #define: Constants are typed, scoped, and visible to the debugger — none of the preprocessor footguns.
• vs Rust const: Similar in spirit but Rust has both const and static; Go has only const for compile-time and package-level var for runtime singletons.

• Arithmetic: +, -, *, /, % (modulo, integer types only).
• Comparison: ==, !=, <, >, <=, >=. All return bool.
• Logical: &&, ||, !. Short-circuit evaluation, just like C.
• Bitwise: & (AND), | (OR), ^ (XOR — also unary NOT), << (left shift), >> (right shift), &^ (AND NOT — bit clear, unique to Go).
• Assignment: =, := (declare + assign), and compound forms +=, -=, *=, /=, %=, &=, |=, ^=, <<=, >>=, &^=.
• Misc: & (address-of), * (dereference), <- (channel send/receive), ... (variadic spread).

• No ternary operator — cond ? a : b doesn't exist. You must write a full if statement. The Go team explicitly rejected ternary because it produces hard-to-read nested chains.
• ++ and -- are statements, not expressions. x++ is valid as a standalone line, but you can never write y = x++ or arr[i++]. Also no prefix form ++x.
• No implicit conversions. int(x) + int(y) won't compile if one is int32 and the other is int64 — you must explicitly convert.
• No operator overloading. Custom types cannot define + or ==. big.Int.Add(a, b) is method-based.
• Simpler precedence than C — only 5 levels instead of 15. This eliminates whole categories of "wait, does & bind tighter than +?" confusion.
• Bit-clear &^ is a unique convenience: x &^ y is the same as x & (^y), useful for clearing bits in a flag set.

• Standard if: if cond { ... } else if ... { ... } else { ... } — no parentheses, mandatory braces.
• if with init: if v, err := f(); err != nil { ... } — declares v and err scoped to the if/else blocks only.
• C-style for: for i := 0; i < 10; i++ { ... }
• While-style for: for cond { ... }
• Infinite loop: for { ... } (with break to exit)
• Range loop: for i, v := range slice { ... } — works on slices, arrays, maps, strings, and channels.
• Value switch: switch x { case 1: ... case 2, 3: ... default: ... }
• Tagless switch: switch { case x > 0: ... case x < 0: ... } — a clean if-else chain.
• Type switch: switch v := x.(type) { case int: ... case string: ... }

• No while or do-while — Go realized you don't need three loop keywords when one suffices. Use for cond { } as a while loop.
• Conditions take no parentheses, but braces are mandatory — even single-line bodies need { }. This eliminates the C/Java dangling-else and Apple-goto-fail bug class.
• Switch cases don't fall through by default — the exact opposite of C/Java/JS. You must explicitly write fallthrough on the rare occasion you want it. This eliminates an entire category of "I forgot to break" bugs.
• Switch is much more powerful — it can compare values, ranges (via tagless form), types (via .(type)), and supports multiple values per case.
• The init statement on if and switch is unique to Go among mainstream languages — it scopes temporary variables tightly.

• Slice/array: for i, v := range s — i is index, v is a copy of the element.
• Map: for k, v := range m — order is randomized on every iteration!
• String: for i, r := range s — i is byte offset, r is a rune (decoded UTF-8 code point).
• Channel: for v := range ch — receives until the channel is closed.
• Integer (Go 1.22+): for i := range 10 — loops 0..9.
• Loop variable scoping (Go 1.22+): Each iteration gets a fresh i and v, fixing the long-standing closure-capture footgun.

• Multiple return values: func divmod(a, b int) (int, int) { return a/b, a%b }
• Named returns: func split(sum int) (x, y int) { x = sum * 4 / 9; y = sum - x; return } — bare return returns the named values.
• Variadic: func sum(nums ...int) int — call as sum(1, 2, 3) or sum(slice...).
• Multiple assignment from one return: v, ok := m[key] — the comma-ok idiom.
• Blank identifier: _, err := f() — discard a return value you don't need.
• Anonymous closures: add := func(a, b int) int { return a + b }
• Method values and method expressions: f := user.Save binds the receiver into a callable.

• Multiple returns are native — no tuples (Python), no out parameters (C#), no destructuring tricks. The compiler treats them as first-class.
• No function overloading — each name maps to exactly one function. Forces meaningful names like ParseInt/ParseFloat instead of overloaded parse(...).
• No default arguments — use the functional-options pattern instead (NewServer(WithPort(8080), WithTLS(cert))).
• No method overloading either — one method name per type.
• Parameter type goes after the name — x int, not int x. Multiple params of the same type can share: func add(a, b, c int).
• Functions are values — much more so than Java but similar to JS/Python first-class functions.

• (value, error) return: data, err := json.Marshal(x) — universal Go shape.
• Higher-order middleware: func Logger(next http.Handler) http.Handler — wrap a handler to add behavior.
• Functional options: NewClient(WithTimeout(5*time.Second), WithRetries(3)).
• Defer + named return for error wrapping: defer func() { err = fmt.Errorf("Foo: %w", err) }()
• Closures in http.HandlerFunc: capture dependencies (db, logger) without globals.

• PascalCase: exported types, functions, constants, vars, struct fields, methods. Example: CalculateArea, UserInfo, MaxRetries.
• camelCase: unexported (private) versions of all of the above. Example: calculateArea, userInfo, maxRetries.
• Acronyms: always all caps in both PascalCase and camelCase contexts. HTTPClient, parseURL, getJSONPayload, userID. Never HttpClient or parseUrl.
• Package names: short, lowercase, single word, no underscores. http, json, fmt, strconv. Never http_client or HTTPClient.
• File names: snake_case if multi-word: user_handler.go, tcp_server.go. Test files end in _test.go.
• Receivers: short, often 1–2 letters reflecting the type. func (u *User) Save(), func (s *Server) Start(). Never self or this.
• Local variables: short and contextual. Loop index = i, byte buffer = buf, context = ctx, error = err.
• Constructors: NewX returns a value, NewXFromY for alternative constructors. Returning *X is common.
• Interface names: often -er suffix for single-method interfaces — Reader, Writer, Stringer, Closer.
• Errors: exported sentinel errors are ErrXxx: io.EOF, sql.ErrNoRows. Error types are XxxError: os.PathError.

• vs Java/C#: No public/private/protected keywords — case is the access modifier. Java prefers verbose names like UserAccountManagerFactory; Go prefers short names like users.
• vs Python: Python uses _underscore as a "private by convention" hint with no enforcement; Go's case rule is compiler-enforced.
• vs JavaScript: JS has #private fields now but the wider ecosystem is inconsistent. Go is uniform.
• vs Ruby: Ruby uses naming for hints (@instance, @@class, $global) but allows almost anything; Go is much stricter.

• Package main's dependencies are initialized first, in topological order — a package's deps are fully initialized before the package itself.
• Within a package, all package-level variable declarations are evaluated first (in dependency order, not source order).
• Then all init() functions in the package run, file by file, in the order the files appear to the compiler (typically alphabetical).
• Finally, main.main() runs.
• If init() panics, the program never starts.

• vs Java static blocks: Java has static {} blocks but their order across classes is lazy (on first use). Go's order is eager and fully specified before main runs.
• vs Python __init__.py: Python module init runs on first import; Go runs all package inits before main.
• vs C++ static constructors: Go's order is well-defined and deterministic; C++'s "static initialization order fiasco" is gone.
• os.Exit vs panic: panic unwinds the stack, runs defer functions, can be caught with recover. os.Exit terminates immediately, skipping all of that — use it at the very top of main after error logging.
• vs return from main: return from main exits with status 0 and runs deferred functions; os.Exit(0) exits with status 0 but skips defers.

• Don't use init() for things that can fail in interesting ways — there's no way to handle errors gracefully. A panicking init() kills the binary at startup with no chance to log nicely.
• os.Exit bypasses defers, so files won't be flushed and locks won't be released. Reserve it for the last line of main after explicit cleanup.
• Multiple init()s in one file all run, in source order — but relying on this is fragile; prefer one init() per file.
• Hidden global state in init() makes packages hard to test in isolation. Use explicit NewX() constructors when you can.

• Pointer — to the first element of the backing array.
• Length (len(s)) — number of elements you can access.
• Capacity (cap(s)) — total space in the backing array from the slice's start.

• Literal: s := []int{1, 2, 3}
• make with length: s := make([]int, 5) → length 5, all zeros, capacity 5.
• make with length + capacity: s := make([]int, 0, 100) → length 0, capacity 100. The pre-allocation prevents repeated re-grows.
• Slicing an existing slice/array: s[2:5], s[:5], s[2:], s[:] — all O(1), share the backing array.
• Three-index slice: s[2:5:7] — limits the new slice's capacity to 5 (7-2), preventing it from extending into the original.

• vs Java/C# arrays: Go arrays are value types — passing one to a function copies it entirely. Java/C# arrays are reference types.
• vs Python lists / JS arrays: Go slices are strongly typed ([]int only holds ints) and contiguous in memory — much faster cache locality, no boxing.
• vs C arrays: Slices know their length — there's no separate length parameter, no array-decay-to-pointer, and no buffer overflows past len.
• vs Rust Vec: Go slices are simpler (no ownership), but with the same shared-backing-array gotchas you don't get in Rust.

• Append may or may not mutate the original. After b := append(a, x), a may or may not see x depending on whether cap(a) > len(a). Always reassign: a = append(a, x).
• Subslices share memory. b := a[2:5] means writes through b are visible through a and vice versa.
• Slice keeps the backing array alive. Slicing a 1 GB file's bytes to extract 10 chars keeps the whole GB in memory. Use copy to detach.
• Pre-allocate when you know the size: make([]T, 0, n) avoids repeated re-grows in tight loops.
• Nil slice vs empty slice: both have length 0; both work with append; the difference matters only for JSON marshaling and pointer equality.

• Literal: m := map[string]int{"a": 1, "b": 2}
• Empty with make: m := make(map[string]int) or with size hint make(map[string]int, 100)
• Insert/update: m["key"] = 42
• Read: v := m["key"] (returns zero value if absent), or v, ok := m["key"] (with existence check).
• Delete: delete(m, "key") — no-op if missing, never panics.
• Length: len(m)
• Iterate: for k, v := range m { ... } — order is randomized!
• Clear (Go 1.21+): clear(m) removes all entries.

• vs Python dict: Iteration order is intentionally randomized on every program run, not insertion-order like Python 3.7+. This is a deliberate language design choice to prevent you from accidentally depending on order.
• vs Java HashMap: Maps are a built-in language type with literal syntax — no HashMap<String, Integer> ceremony, no autoboxing.
• vs C++ std::map: Go's map is a hash table (O(1)), not a tree (O(log n)). Closer to std::unordered_map.
• vs JavaScript objects: Real strong typing on keys and values; no prototype chain weirdness.
• NOT thread-safe: Concurrent reads are fine, but any concurrent write with another read or write triggers a runtime panic. Use sync.Map or wrap with sync.RWMutex.
• Nil maps: A nil map can be read from (returns zero values) and ranged over (zero iterations) but panics on write.

• Set: set := map[string]struct{}{} — struct{} uses zero bytes per value.
• Counter: counts := map[string]int{}; counts[word]++ (zero value of int is 0).
• Lookup table: statusText := map[int]string{200: "OK", 404: "Not Found"}
• Group-by: groups := map[string][]Item{}; groups[k] = append(groups[k], item)
• Concurrent cache: wrap a regular map with sync.RWMutex; reach for sync.Map only for read-mostly workloads with disjoint keys.

• len("hello") → 5 (each ASCII char is 1 byte)
• len("héllo") → 6 (the é takes 2 bytes in UTF-8)
• len("世界") → 6 (each CJK character takes 3 bytes)
• len("🔥") → 4 (the fire emoji is a 4-byte code point)
• To count characters, not bytes: utf8.RuneCountInString(s) or len([]rune(s)).

• vs Java/C# String: Java strings are sequences of UTF-16 code units (2 bytes each). Go strings are byte sequences with no enforced encoding — though almost always UTF-8.
• vs Python str: Python 3 str is character-oriented and abstracts away encoding. Go is byte-oriented and explicit — sometimes more work, but never surprising.
• vs C strings: Not null-terminated! Go strings know their length, so they can contain \0 bytes harmlessly.
• vs JS strings: JS uses UTF-16; "𝄞".length === 2 because it's a surrogate pair. Go's len("𝄞") is 4 (UTF-8 bytes).
• Immutable — unlike []byte, you cannot do s[0] = 'x'; it's a compile error.
• No char type — use rune for code points ('A' is a rune literal, value 65) or byte for raw octets.

• string ↔ []byte: b := []byte(s) and s := string(b) — both copy. Use unsafe.String/StringData (Go 1.20+) for zero-copy in hot paths.
• string ↔ []rune: r := []rune(s) decodes UTF-8 into a slice of code points. s := string(r) encodes back.
• int → string of one rune: string(65) → "A". (go vet warns about this; use strconv.Itoa for "65".)
• int → decimal string: strconv.Itoa(65) → "65".

• Search: Contains, ContainsAny, HasPrefix, HasSuffix, Index, LastIndex, Count.
• Split/Join: Split, SplitN, SplitAfter, Fields (split on whitespace), Join.
• Replace: Replace, ReplaceAll, NewReplacer for multi-pair replacement.
• Trim: TrimSpace, Trim, TrimLeft, TrimRight, TrimPrefix, TrimSuffix.
• Case: ToLower, ToUpper, Title (deprecated; use cases.Title), EqualFold (case-insensitive equality).
• Build/transform: Repeat, Map (rune mapper), NewReader.
• Assembly: strings.Builder with WriteString, WriteRune, WriteByte, then String().

• Free functions, not methods. Unlike Python (s.split()) or Java (s.toLowerCase()), Go uses package-level functions: strings.Split(s, ","), strings.ToLower(s). This is consistent with Go's "no method call without a receiver type" rule.
• strings.Builder vs Java StringBuilder: Same idea, slightly different API — Go uses WriteString/WriteRune/WriteByte instead of append.
• vs Python "".join(list): The same trick. strings.Join(slice, ",") is the most direct equivalent.
• vs bytes package: The bytes package mirrors strings for []byte — same function names, same semantics. Use it when working with binary data.

• Don't copy a Builder. Once you've called WriteString, copying invalidates the buffer. Use a pointer if you must pass it around.
• Pre-grow with Builder.Grow(n) when you know the output size — avoids repeated re-grows.
• For tiny known concatenations (2–3 fixed strings), plain + is fine and the compiler will optimize. The Builder pays off in loops or when assembling many parts.

• Named (the usual case): declared with type X struct { ... }.
• Anonymous: declared inline as part of a variable or function signature.
• Nested: a struct inside a struct.
• Embedded: a field with no name, promoting the inner type's fields and methods.
• Tagged: with backtick metadata strings used by encoders, validators, and ORMs.

• Zero value: var u User — every field is the type's zero value. This is immediately usable in Go ("useful zero values" is a core philosophy).
• Positional literal: u := User{1, "Yatin", "y@example.com"} — fragile if fields are reordered, almost never used in production.
• Named literal: u := User{ID: 1, Name: "Yatin"} — preferred form; missing fields get zero values; resilient to field additions.
• Pointer literal: u := &User{ID: 1, Name: "Yatin"} — get a heap-allocated pointer in one expression.
• Constructor function: u := NewUser(1, "Yatin", "y@example.com") — convention is NewX returning *X or X.

• vs OOP classes (Java/C#): No inheritance — only composition (embedding). No constructors — use a NewX function if you need one. No methods inside the body — declared separately with func (r Receiver) Method(). No this/self — the receiver name is whatever you choose.
• Value types by default: Assignment, function arguments, and map values copy the entire struct. Use a pointer (*User) if you want sharing or mutation.
• vs C structs: Same memory layout, but with methods, tags, and embedded fields. No bit fields (use uint8 + bitwise ops manually).
• vs Rust structs: Very similar — both are value types with separate impl blocks for methods. Go skips Rust's lifetime annotations and traits.
• Comparable structs: Two structs are == if all fields are ==. Structs containing slices/maps/funcs are not comparable.

• Format: `key1:"value1" key2:"value2,option1,option2"`
• Multiple keys separated by spaces, allowing one field to carry tags for several libraries simultaneously.
• Within a value, comma-separated options refine behavior (e.g. omitempty, required, min=1).
• Reading manually: reflect.TypeOf(x).Field(i).Tag.Get("json") returns the value for that key.

• json: standard library — `json:"name,omitempty"`, `json:"-"` to exclude.
• xml: standard library — `xml:"name,attr"` for attributes.
• yaml: via gopkg.in/yaml.v3.
• db: via jmoiron/sqlx for SQL row mapping.
• gorm: via GORM ORM — `gorm:"primaryKey;autoIncrement"`.
• validate: via go-playground/validator — `validate:"required,email,max=100"`.
• form, uri, header: via Gin framework for binding HTTP request parts.
• env: via caarlos0/env for environment variable binding.
• flag: for CLI flag binding.
• protobuf: generated by protoc-gen-go.

• vs Java/C# annotations: Java uses typed annotations like @JsonProperty("name") with their own classes and runtime support. Go tags are just strings — much lighter, but less type-safe.
• vs Python decorators: Python decorators wrap functions/classes with code. Go tags carry only metadata, never code.
• vs Rust attributes: Rust has #[serde(rename = "name")] which is closer to Java annotations. Go's strings are simpler but require external parsing.
• Multiple libraries can share one field: `json:"id" db:"user_id" validate:"min=1"` — each consumer reads only its own key.

• Unexported fields are skipped by all encoders, regardless of tags. name string `json:"name"` won't appear in JSON output.
• Typos in tags are silent. `josn:"name"` compiles fine but won't be picked up. Use go vet's structtag check.
• omitempty rules vary by encoder. JSON considers zero values "empty"; not all encoders behave the same.
• Tag strings must be a single line — multiline tags don't compile.

• Address-of: p := &x — p has type *int if x is int.
• Dereference (read): v := *p — copies the value p points at.
• Dereference (write): *p = 100 — writes through the pointer.
• New: p := new(int) — allocates a zero-valued int on the heap and returns *int.
• Struct literal pointer: u := &User{Name: "Yatin"} — equivalent to taking the address of a struct literal.
• Method auto-deref: p.Method() automatically dereferences p if needed; you almost never write (*p).Method().
• Field auto-deref: p.Name works whether p is User or *User.
• Nil check: if p == nil { ... } — dereferencing a nil pointer panics.

• vs C/C++: Go has no pointer arithmetic — p++ is illegal. This eliminates buffer overruns, the most common C memory bug. The GC handles cleanup, so no manual free. unsafe exists as an opt-in escape hatch.
• vs Java/Python/JS: In those languages every object is implicitly a reference; you can't choose. Go gives you the choice: User (value, copied on assignment) vs *User (pointer, shared). This explicitness is a big win for performance reasoning.
• vs Rust references: Rust enforces lifetimes and aliasing rules at compile time; Go relies on the GC to keep things safe. Easier to learn, slightly slower.
• Stack vs heap: Go's escape analysis decides automatically — if a pointer "escapes" the function (returned, stored in a global, captured by a goroutine), the value lives on the heap; otherwise on the stack.

• Use a pointer receiver if: the method needs to mutate the receiver, the struct is large (avoid copies), the type contains a sync.Mutex, or you want consistency across all methods of the type.
• Use a value receiver if: the type is small (a few words), it's immutable by nature (e.g. time.Time), and you don't need mutation.
• Don't mix: if any method on a type uses a pointer receiver, all methods should — otherwise the method set rules get confusing for interface satisfaction.

• Nil dereference panic: var p *User; p.Name crashes. Always check or guarantee non-nil.
• Address of map element: &m["key"] is illegal — map values are not addressable.
• Loop variable capture (pre-Go 1.22): for _, x := range slice { go func() { use(&x) }() } — all goroutines see the same address. Fixed in Go 1.22.
• Nil interface vs nil pointer: An interface holding a typed nil pointer is itself not nil. var p *MyError = nil; var e error = p; e == nil → false! Famous footgun.

• Value receiver: func (r Rectangle) Area() — gets a copy of the receiver. Cannot mutate the original. Cheap for small types.
• Pointer receiver: func (r *Rectangle) Scale(f float64) — gets a pointer, can mutate the original, avoids copying for large structs.
• Auto-conversion: calling p.Method() where Method has a pointer receiver works whether p is T or *T (Go inserts & automatically) — but only if the value is addressable.
• Method set rules for interface satisfaction: if interface methods include any pointer-receiver methods, you need a *T, not a T, to satisfy the interface.

• Definition: type Reader interface { Read(p []byte) (n int, err error) }
• Empty interface: interface{} (or its alias any in Go 1.18+) — holds any value. Pre-generics, this was the universal "any type" placeholder.
• Type assertion: v, ok := i.(Concrete) — extract the underlying type.
• Type switch: switch v := i.(type) { case int: ... case string: ... } — branch on the dynamic type.
• Embedding interfaces: type ReadWriter interface { Reader; Writer } — composes the method sets.
• Internal representation: an interface value is a 2-word pair: {type info, data pointer}. The famous "nil interface vs interface holding nil" footgun comes from the type-info word being non-nil.

• vs Java/C# nominal typing: Interface satisfaction is structural / implicit — you never write implements Stringer. If your type has the right method, it satisfies. Java requires explicit declaration of implemented interfaces, which creates tight coupling.
• vs duck typing in Python/Ruby: Same idea ("if it walks like a duck...") but Go checks at compile time, not runtime. You get the flexibility without the runtime errors.
• vs Rust traits: Rust traits are nominal (you must impl Trait for Type). Go interfaces are structural — more flexible but less explicit.
• vs C++ virtual methods: No vtable on the type itself; the interface value carries the method table at runtime, allowing the same type to satisfy unrelated interfaces.
• Methods on non-struct types: Unique among mainstream languages — type MyInt int; func (m MyInt) Double() MyInt is perfectly valid.

• io.Reader — anything you can read bytes from (file, socket, HTTP body, in-memory buffer).
• io.Writer — anything you can write bytes to.
• error — any type with Error() string.
• fmt.Stringer — controls how a value prints with %v.
• http.Handler — anything that can serve an HTTP request.
• sort.Interface — pre-generic sortable collection (Len, Less, Swap).

• Struct in struct: type Dog struct { Animal; Breed string } — promotes fields and methods.
• Interface in interface: type ReadWriter interface { Reader; Writer } — composes method sets.
• Interface in struct: type LoggingReader struct { io.Reader; logger *Logger } — wraps a value satisfying the interface, useful for decorators/middleware.

• dog.Speak() calls Dog's version (if defined) or falls back to Animal's.
• dog.Animal.Speak() always calls Animal's version explicitly.
• This is the closest Go gets to a super call.
• If two embedded types have the same method name, you must call them via the explicit form to disambiguate — there's no automatic resolution.

• vs class inheritance (Java/C++/Python): Embedding looks like inheritance but isn't. It's "has-a" with method promotion. There's no virtual dispatch on the outer type, no super keyword, no protected/private hierarchy, no "is-a" subtype relationship.
• The embedded type knows nothing about the outer. A method defined on Animal cannot call methods overridden on Dog — there's no polymorphism the way Java provides.
• vs traits/mixins: Closer to Rust traits or Scala mixins than to classical inheritance. Pure composition, no fragile base class problem.
• vs Object.assign / spread: JS-style copying mixes properties at runtime; Go's embedding is a compile-time structural feature.

• http.ServeMux: embeds a sync.Mutex directly so methods can call m.Lock() as if it were their own.
• Middleware decoration: type LoggingHandler struct { http.Handler } wraps any handler, overrides ServeHTTP, and can call the embedded version via h.Handler.ServeHTTP(w, r).
• Test fakes: embed an interface in a test struct, override only the methods you care about, the rest will panic on call (nil pointer) — explicit signal that the test exercised the wrong path.
• Domain hierarchies: type Admin struct { User; Permissions []string } — gets all User methods plus its own.

• The interface: type error interface { Error() string } — that's the entire definition.
• Static text errors: errors.New("not found") — produces an immutable error value.
• Sentinel errors: package-level var ErrNotFound = errors.New("not found") — comparable with == or errors.Is.
• Formatted errors: fmt.Errorf("user %d: %w", id, err) — the %w verb wraps another error to preserve the chain.
• Custom error types: any struct implementing Error() string; can carry rich context (HTTP status, retry hints, fields).

• errors.Is(err, target) — walks the wrap chain, returns true if any link equals target. Use this for sentinel comparisons: errors.Is(err, sql.ErrNoRows).
• errors.As(err, &target) — walks the chain looking for an error of type target; if found, sets it. Used for typed errors carrying data.
• errors.Unwrap(err) — returns the next error in the chain (or nil).
• errors.Join(errs...) (Go 1.20+) — combines multiple errors into one.

• vs Python/Java/JS exceptions: No try/catch. Errors don't unwind the stack — they flow through return values like any other data. Every line is not a potential throw site, which makes control flow predictable.
• vs Rust Result<T, E>: Same idea — error as value — but Rust uses an enum and the ? operator to bubble up. Go has no equivalent of ?; you write if err != nil { return ..., err } by hand.
• vs Go panic: panic exists for unrecoverable bugs (nil deref, index out of range, programmer assertion failures). It is not the normal error mechanism — using it for ordinary failures is considered very un-Go.
• The famous verbosity: Yes, you'll write if err != nil { return err } a lot. The trade-off is that every error site is visible in the source — no surprise exceptions, no missed handlers.

• Wrap with context at each layer: fmt.Errorf("loading user %d: %w", id, err). Don't return err bare from deep call chains.
• Use sentinel errors for "expected" failure modes the caller should handle (io.EOF, sql.ErrNoRows).
• Use typed errors when you need to carry data (HTTP status code, validation field name).
• Don't log AND return the same error — pick one. Logging at the top of the call stack avoids duplicate noise.
• Compare with errors.Is, not ==, in modern code so wrapping doesn't break checks.
• Reserve panic for "programmer error" situations: package init failures, impossible-state assertions.

• String → int: strconv.Atoi("42") → (42, nil). The shortcut for ParseInt(s, 10, 0).
• String → int with base/size: strconv.ParseInt("ff", 16, 64) → (255, nil).
• String → uint: strconv.ParseUint("42", 10, 64)
• String → float: strconv.ParseFloat("3.14", 64)
• String → bool: strconv.ParseBool("true") — accepts "1", "t", "T", "TRUE", "true", "True", and the falses.
• Int → string: strconv.Itoa(42) → "42". Shortcut for FormatInt(int64(i), 10).
• Float → string: strconv.FormatFloat(3.14, 'f', 2, 64) → "3.14".
• Bool → string: strconv.FormatBool(true) → "true".
• Quote: strconv.Quote("hi\n") → "\"hi\\n\"" — Go-syntax string literal.

• vs JavaScript: JS has weak typing — "5" + 1 === "51" and "5" * 1 === 5. Go won't compile either expression — you must explicitly call strconv.Atoi("5") or fmt.Sprintf("%s%d", s, i).
• vs Python: Python raises TypeError at runtime for similar mistakes. Go catches them at compile time.
• vs Java: Java has implicit widening (int → long) but explicit narrowing. Go is fully explicit in both directions: int + int64 doesn't compile.
• Conversion syntax: Always TargetType(value) — looks like a function call. There's no v as T (Rust/TS) or C-style (T)v.
• Parsing returns an error, conversions don't — a critical distinction. int(3.7) just truncates to 3; strconv.Atoi("hi") returns an error.

• string(65) is "A", not "65" — converting an int to string treats it as a Unicode code point. go vet warns. Use strconv.Itoa(65) for "65".
• Float to int truncates, doesn't round: int(3.9) → 3. Use math.Round first if you need rounding.
• Narrowing conversions silently overflow: int8(300) → 44, no panic, no warning. The race detector and govet's shift check help.
• String ↔ []byte converts copy memory by default. Use unsafe.String/StringData (Go 1.20+) in hot paths to avoid the copy.

• Print/Println/Printf → write to os.Stdout
• Sprint/Sprintln/Sprintf → return a string
• Fprint/Fprintln/Fprintf → write to any io.Writer (file, network, buffer)
• Errorf → returns an error (the modern way to construct wrapped errors with %w)
• Scan/Scanln/Scanf → read from stdin (rarely used; bufio.Scanner is more common)
• Sscan/Sscanf → parse from a string

• General: %v default format, %+v with field names, %#v Go-syntax, %T type name, %% literal percent.
• Boolean: %t → "true"/"false".
• Integer: %d decimal, %b binary, %o octal, %x/%X hex, %c Unicode char, %U Unicode point.
• Float: %f/%F decimal, %e/%E scientific, %g/%G shortest, %.2f precision.
• String: %s raw, %q double-quoted, %x hex bytes.
• Pointer: %p hex pointer address.
• Errors: %w — wraps an error so it can be unwrapped with errors.Unwrap/Is/As. Only valid in fmt.Errorf.
• Width and padding: %10d right-aligned in 10 cols, %-10d left-aligned, %010d zero-padded.

• vs C printf: Go verbs are type-checked by go vet — passing the wrong arg type for a verb is caught before the program runs. C's printf is happy to crash at runtime if you mismatch %d with a pointer.
• vs Python f-strings: Python's f-strings are nicer for inline interpolation but only work at compile time. fmt.Sprintf works on dynamic format strings.
• The %v verb is unique: it inspects the value's type via reflection and renders it sensibly — works on structs, slices, maps, channels, even functions.
• Custom formatting: implement fmt.Stringer (String() string) to control how your type prints with %v and %s. Implement fmt.Formatter for full control.
• Error wrapping (%w) is unique — it builds the error chain that errors.Is/errors.As walk.

• Match: MatchString(s) → just true/false.
• Find: FindString(s) → first match. FindAllString(s, -1) → all matches.
• FindSubmatch: FindStringSubmatch(s) → match + capture groups as []string.
• FindIndex: returns byte offsets instead of strings — useful for replacement.
• Replace: ReplaceAllString(s, "$1-$2"), ReplaceAllStringFunc(s, func(match string) string {...}).
• Split: Split(s, -1) — split on every match.
• Named groups: (?P<name>...) in pattern, SubexpIndex("name") to look up.

• Lost features: No backreferences (\1 in the pattern), no lookahead/lookbehind ((?=...), (?<=...)), no recursive subpatterns.
• What you get in exchange: guaranteed linear time matching. RE2 cannot suffer "catastrophic backtracking" — the kind of pathological pattern that makes a PCRE-based service hang for minutes on a malicious input.
• Same syntax for common features: character classes [a-z], anchors ^$, quantifiers *+?{n,m}, alternation |, capture groups (...), non-capturing groups (?:...), named groups (?P<name>...), flags (?i).
• Same trick as Rust's regex crate, which also descends from RE2.

• Always compile once. Compiling inside a loop is 100× slower than reusing a compiled pattern.
• Use raw strings (backtick): `\d+` not "\\d+".
• Anchor your patterns with ^ and $ when matching whole strings — much faster than scanning.
• Don't regex when strings works: strings.HasPrefix beats ^foo; strings.Contains beats foo.
• For performance-critical parsing (URLs, logs, structured text), hand-written parsers are usually 5–20× faster than regex.

• Base case: the condition where the function returns directly without recursing — this is what stops the chain.
• Recursive case: the self-call with a strictly smaller input (or one closer to the base case).

• Direct recursion: a function calls itself directly. factorial(n) → n * factorial(n-1).
• Mutual recursion: two or more functions call each other. isEven(n) calls isOdd(n-1) and vice versa.
• Tail recursion: the recursive call is the very last action; the result is returned directly. Some languages optimize this into a loop — Go does not.
• Tree recursion: the function calls itself multiple times per call. fib(n) = fib(n-1) + fib(n-2). Without memoization, exponential blowup.
• Recursion with accumulator: pass partial results down to make tail-style recursion efficient.
• Backtracking: recursion + state mutation + undo. Sudoku solvers, N-queens, maze exploration.

• No tail-call optimization (TCO). Unlike Scheme, Scala, or Haskell, Go does not rewrite tail-recursive calls into loops. Deep tail-recursive Go code grows the stack and can panic with stack overflow.
• BUT goroutine stacks are dynamic. They start at ~2 KB and grow on demand up to GOMAXSTACK (default 1 GB). This means Go can typically handle deeper recursion than fixed-stack threads in C/Java.
• Mutual recursion just works: Go resolves names lazily within a package, so two functions can call each other without forward declarations.
• vs Python: Python's default recursion limit is 1000 — you'll RecursionError long before Go would.
• vs JavaScript: JS has no TCO either (despite the spec) and a much smaller default stack — recursion depth often maxes out around 10,000.

• The recursion depth could be unbounded (input from user/network).
• You're seeing exponential time blowup without memoization.
• The hot path runs in a tight loop where call overhead matters.
• You're recursing only at the tail position — replace with a loop.
• Use an explicit stack ([]Item) when you need recursion semantics but no stack risk.

• math/rand (and Go 1.22's math/rand/v2) — fast, deterministic, pseudo-random numbers. Good for games, simulations, sampling, randomized testing, randomized backoff, picking a random element from a slice. NOT secure.
• crypto/rand — slower, cryptographically secure random bytes from the OS entropy source (/dev/urandom on Unix, CryptGenRandom on Windows). Use for passwords, session tokens, API keys, salts, nonces, anything an attacker shouldn't be able to predict.

• Random int in [0, n): rand.Intn(n)
• Random int64: rand.Int63()
• Random float in [0, 1): rand.Float64()
• Shuffle a slice: rand.Shuffle(len(s), func(i, j int) { s[i], s[j] = s[j], s[i] })
• Seed (only if you need reproducibility): r := rand.New(rand.NewSource(42)) — same seed always produces the same sequence.
• Auto-seeding (Go 1.20+): the global functions are auto-seeded per program — no more rand.Seed(time.Now().UnixNano()) ritual.

• Random bytes: b := make([]byte, 32); _, err := rand.Read(b)
• Random integer in range: n, err := rand.Int(rand.Reader, big.NewInt(100))
• Random hex token: b := make([]byte, 16); rand.Read(b); token := hex.EncodeToString(b)
• Random URL-safe base64 token: base64.URLEncoding.EncodeToString(b)
• Always check the error — entropy can fail in weird containerized environments.

• vs Python: Python has a single random module by default; you have to know to import secrets for crypto-grade randomness. Go cleanly separates the two intents at the package level, making the right choice obvious.
• vs Java: Java has Random, ThreadLocalRandom, and SecureRandom — same split, different names. Go's two-package design is clearer.
• vs Node.js: Node has Math.random() (insecure) and crypto.randomBytes() — same pattern but with the same naming pitfall as Python.
• Performance gap: math/rand is ~5–10ns per int. crypto/rand is ~100–500ns depending on OS — fast enough for tokens, slow enough that you wouldn't use it for a Monte Carlo simulation.

• Pre-Go 1.20, math/rand with no seed always produced the same sequence — code that "worked in tests" was deterministic by accident.
• Modulo bias: using n % 100 on a uniformly random uint64 introduces a tiny bias. Use rand.Intn(100) which handles this.
• Concurrent use: math/rand's default global is safe for concurrent use but contended; for hot loops, give each goroutine its own *rand.Rand.
• Don't roll your own crypto. Even with crypto/rand, password hashing wants bcrypt/argon2, not raw SHA-256.

• time.Time — a single moment in time, with nanosecond precision and a time zone.
• time.Duration — a typed int64 that counts nanoseconds. 5 * time.Second, 30 * time.Minute, 24 * time.Hour.
• time.Location — a time zone (e.g. time.UTC, time.Local, or one loaded by name).

• Now: now := time.Now()
• Specific time: time.Date(2026, time.April, 8, 12, 0, 0, 0, time.UTC)
• Parse: t, err := time.Parse("2006-01-02", "2026-04-08")
• Format: now.Format("2006-01-02 15:04:05")
• Add/subtract: future := now.Add(24 * time.Hour), diff := t2.Sub(t1) (returns Duration).
• Compare: t1.Before(t2), t1.After(t2), t1.Equal(t2) (use Equal, not ==!).
• Unix epoch: now.Unix() (seconds), now.UnixMilli(), now.UnixNano(); reverse with time.Unix(secs, nsec).
• Sleep: time.Sleep(2 * time.Second)
• Time zone: loc, _ := time.LoadLocation("America/New_York"); now.In(loc)
• Truncate/Round: now.Truncate(time.Minute) — drop seconds and below.

• "2006-01-02" → ISO date
• "2006-01-02T15:04:05Z07:00" → RFC 3339 (the standard Go uses internally)
• "02/01/2006" → European format
• "Mon, 02 Jan 2006 15:04:05 GMT" → HTTP date format
• Pre-defined constants: time.RFC3339, time.RFC822, time.Kitchen, etc.

• vs Python strftime: Python uses cryptic codes like %Y-%m-%d %H:%M:%S that you have to memorize. Go uses an example date you read literally.
• vs Java SimpleDateFormat: Java's yyyy-MM-dd HH:mm:ss is a different mini-language, and SimpleDateFormat isn't thread-safe (a famous footgun). Go's Format is fully thread-safe and the layout is literal.
• vs JavaScript Date: JS's Date is famously broken (months are 0-indexed, no immutable type, no time zones). Go's API is sound.
• Typed durations: time.Duration is unique — it makes 5 * time.Second a compile-time-checked value. You literally cannot pass a raw int where a duration is expected.
• Monotonic clock: Go's time.Now() includes a monotonic reading, so t2.Sub(t1) works correctly even if the wall clock jumps (NTP, DST).

• Use t1.Equal(t2), not t1 == t2. The struct comparison includes the location pointer, so two times that represent the same instant in different zones are not ==.
• Time zone parsing fails on minimal Linux containers without IANA data. Either install tzdata or import _ "time/tzdata" to embed it.
• Don't store times as strings — use time.Time + JSON's RFC 3339 marshaling.
• UTC for storage, local for display. Always.

• Initial stack size: ~2 KB (vs ~1 MB for an OS thread).
• Dynamic stack growth: stacks grow and shrink in segments as needed, up to GOMAXSTACK (default 1 GB).
• M:N scheduler: Go's runtime multiplexes M goroutines onto N OS threads (where N = GOMAXPROCS, typically the CPU count).
• Cooperative + preemptive: goroutines yield at function calls, channel ops, syscalls; since Go 1.14, also preemptively at safe points to prevent CPU-bound goroutines from starving the scheduler.
• You can run millions of goroutines on a single machine — far beyond what OS threads allow.
• Cheap to create: ~10× faster than spawning an OS thread.

• Create: ch := make(chan int) (unbuffered) or make(chan int, 100) (buffered, capacity 100).
• Send: ch <- 42 — blocks until a receiver is ready (or buffer has space).
• Receive: v := <-ch — blocks until a sender provides a value (or buffer has data).
• Close: close(ch) — signals "no more values"; receivers see zero value + ok=false.
• Range: for v := range ch { ... } — receives until the channel is closed.
• Direction: a function param can require send-only (chan<- T) or receive-only (<-chan T) for safety.

• vs Java threads: Java threads map 1:1 to OS threads (~1 MB each) and use locks/condition variables for coordination. Go goroutines are 500× lighter and channels remove most lock usage.
• vs Node.js: Node has a single-threaded event loop with async/await. Great for I/O, terrible for CPU work. Go goroutines give you both async I/O and true CPU parallelism with no special syntax.
• vs Python asyncio: Async coroutines but the GIL prevents true parallelism. Plus the entire ecosystem has to be "async-aware" (function coloring problem). Go has no function coloring.
• vs C++ std::thread: Heavy OS threads + manual synchronization. Modern C++ is adding coroutines but they're complex.
• vs Erlang processes: Closest in spirit — both have lightweight processes and message passing. Go is faster but lacks Erlang's preemption guarantees.
• vs Rust async: Rust has zero-cost async but with steep learning curve (Pin, Send, Sync, lifetimes). Go is much simpler.

• WaitGroup: wait for N goroutines to finish before continuing.
• Worker pool: N goroutines reading from a shared jobs channel.
• Fan-out: one producer feeds N consumers via the same channel.
• Fan-in: N producers send to one channel; one consumer aggregates.
• Pipeline: stage1 → channel → stage2 → channel → stage3, each stage a goroutine.
• Cancellation via context: select { case <-ctx.Done(): return; case ... }

• Goroutine leaks: a goroutine blocked on a channel that never receives runs forever. Always have a way out — context, timeout, or close.
• Loop variable capture (pre-1.22): for _, v := range s { go f(v) } — all goroutines saw the same v. Fixed in Go 1.22.
• Sending to a closed channel panics. Receiving from one returns zero value + ok=false.
• Don't close a channel from the receiver side — only the sender knows when it's done.

• Unbuffered channels — sender and receiver rendezvous: both block until both are ready.
• Buffered channels — capacity > 0; send blocks only when full, receive blocks only when empty.
• Directional channels — chan<- T (send-only) and <-chan T (receive-only) for type-safe API contracts.
• Closing channels — close(ch) signals "no more values"; receivers detect with the comma-ok idiom.
• Channel as a synchronization primitive — using sends/receives as signals, not just data transfer.
• Nil channels — sending to or receiving from a nil channel blocks forever; useful in select to disable cases.

• Unbuffered (make(chan int)): A pure handoff. Sender blocks until a receiver is ready; receiver blocks until a sender provides. Guarantees happens-before: the send completes before the receive returns. Use when you need synchronization or a "bounded queue of size 1 in flight".
• Buffered (make(chan int, n)): Acts like a bounded FIFO queue. Sends only block when the buffer is full; receives only block when it's empty. Use when producer and consumer have different rates and you want to absorb bursts.
• Choosing capacity: 0 = synchronous handoff. Small (1–10) = decouple producer/consumer slightly. Large = pure queue (be careful — large buffers hide latency problems).

• Only the sender should close. Never close from the receiver side — you might race the sender and panic.
• Sending on a closed channel panics — irrecoverable.
• Receiving from a closed channel returns the zero value and ok = false: v, ok := <-ch.
• Range loops (for v := range ch) automatically exit when the channel is closed and drained.
• Closing a nil channel panics.
• Closing twice panics.
• You don't have to close every channel. Garbage collection will clean up channels with no remaining references. Close only to signal "no more data" to receivers.

• func produce(out chan<- int) — function may only send to out; trying to read is a compile error.
• func consume(in <-chan int) — function may only receive from in; trying to send is a compile error.
• A bidirectional chan T can be implicitly converted to either direction; the reverse is not allowed.
• This is your most powerful API documentation tool — the type system enforces the protocol.

• vs queues in libraries (Java BlockingQueue, Python queue.Queue): Those are heap objects with method-call overhead. Go channels are part of the runtime — the scheduler can park/wake goroutines almost for free when they block.
• Direction typing is unique — no mainstream queue library lets you statically prevent a producer from reading.
• vs Erlang messages: Erlang has typeless mailboxes per process. Go channels are typed pipes between any two goroutines, more flexible but less actor-like.
• vs Rust mpsc: Similar in spirit but Rust splits sender and receiver into two types; Go uses one channel value with direction-cast on function args.

• Done channel: done := make(chan struct{}); <-done as a wait-forever signal; close(done) to release everyone.
• Quit channel: close-as-broadcast cancellation.
• Semaphore: buffered channel of size N as a counting semaphore — sem <- struct{}{} to acquire, <-sem to release.
• Barrier: close an unbuffered channel after all workers have signaled.
• Generator: a goroutine that pushes values onto a channel until exhausted, then closes.

• default case — runs immediately if no other case is ready, making select non-blocking.
• No cases ready, no default — the goroutine blocks until any case becomes ready.
• Empty select {} — blocks forever, occasionally used to keep the main goroutine alive.
• Nil channels in cases — never ready, effectively disabling that case.

• Multi-way receive: wait for whichever channel produces first.
• Receive with timeout: case <-time.After(5 * time.Second): return ErrTimeout
• Non-blocking receive: select { case v := <-ch: ...; default: ... } — try to read, fall back if nothing's there.
• Non-blocking send: select { case ch <- v: ...; default: ... } — try to send, drop the message if nobody's listening.
• Cancellation watch: case <-ctx.Done(): return ctx.Err() — the canonical Go cancellation idiom.
• Heartbeat: case <-ticker.C: sendHeartbeat() alongside the work case.

• vs switch: syntactically similar, semantically very different. Switch compares values; select waits on channel operations.
• vs Unix select(2) / epoll: Same idea (wait on many I/O operations) but at the language level for arbitrary typed channels, not file descriptors.
• vs Java Selector / BlockingQueue.poll: Java requires manual loops and explicit polling. Go's select is one expression.
• vs Node.js / Python asyncio: Other languages need Promise.race or asyncio.wait with callback chains. Go has a single blocking, multi-way primitive built into the syntax.
• vs Rust tokio::select!: Rust now has an analogous macro, inspired in part by Go.
• Random selection when multiple cases are ready is unique — prevents one channel from monopolizing if it's always ready.

• Cancellable receive: select { case v := <-work: handle(v); case <-ctx.Done(): return }
• Timeout wrapper: select { case r := <-resp: return r; case <-time.After(timeout): return ErrTimeout }
• Drop on overflow: non-blocking send to a buffered channel; if full, drop the metric/log and increment a counter.
• Throttle: wait on a ticker channel before each operation.
• Disable a case dynamically: set the channel variable to nil — that case becomes unreachable.

• time.After leaks in long loops: each call allocates a new timer that lives until it fires. In tight loops, prefer time.NewTimer + Reset.
• The order of cases in source doesn't matter — selection is random when multiple are ready.
• Nested selects can be confusing; consider extracting helper functions.
• Receiving from a closed channel always succeeds immediately — useful as a broadcast cancel signal, but means a closed channel "wins" every selection.

• Jobs channel: producer-to-worker conduit, typically chan Job.
• Results channel: worker-to-collector conduit, typically chan Result. Buffered to match concurrency.
• N worker goroutines: each runs for job := range jobs { results <- process(job) }.
• WaitGroup: tracks workers so the collector knows when to close results.
• Closer goroutine: after wg.Wait(), calls close(results) so the consumer's range loop terminates.
• Optional context: for cancellation; workers select between jobs and ctx.Done().

• vs Java ExecutorService / ThreadPoolExecutor: Java's pools are heavy library types with config classes, factory methods, and shutdown protocols. A Go worker pool is ~20 lines of plain code using just goroutines, channels, and WaitGroup. The pattern is the framework.
• vs Python concurrent.futures: Same idea but Python's GIL means CPU-bound work doesn't actually parallelize. Go workers run on real OS threads.
• vs Node.js worker_threads: Heavy and rarely used; Node prefers event loop. Go pools combine the best of both.
• vs unbounded "goroutine per request": Spawning a goroutine per HTTP request seems convenient but can blow up under load — exhausting file descriptors, overloading downstreams, or triggering OOM. A pool gives you a natural admission gate.

• CPU-bound work: N = runtime.NumCPU() or slightly less.
• I/O-bound work: N can be much higher — 50 to 500 — since workers spend most time waiting.
• Mixed: measure with pprof and a load test; the right number is rarely guessable.
• Per-resource limits: if each worker holds a DB connection, N ≤ pool size − safety margin.

• Errgroup pattern: use golang.org/x/sync/errgroup — combines WaitGroup, error capture, and context cancellation in one type.
• Bounded semaphore: a buffered channel of size N as a counting semaphore — even simpler than a pool when you don't need long-lived workers.
• Pipelined pools: several pools connected in stages, each transforming output of the previous.
• Pull vs push: workers pulling from a channel scales naturally; pushing to specific workers requires routing logic.

• time.Timer — fires once after a specified duration. Created with time.NewTimer(d) or time.AfterFunc(d, fn). Exposes a channel C on which it sends the current time when it fires.
• time.Ticker — fires repeatedly at a fixed interval. Created with time.NewTicker(d). Exposes a channel C that periodically delivers the current time.

• Create timer: t := time.NewTimer(5 * time.Second)
• Wait for fire: <-t.C
• Stop early: t.Stop() — returns true if successfully stopped before firing.
• Reset: t.Reset(d) — reuse the timer with a new duration.
• Create ticker: tk := time.NewTicker(1 * time.Second)
• Read tick: <-tk.C in a loop or select.
• ALWAYS stop tickers: defer tk.Stop() — otherwise the runtime keeps sending forever.
• One-shot inline: case <-time.After(2 * time.Second): // timeout

• vs JavaScript setTimeout/setInterval: JS uses callbacks; Go uses channels. Go's channel-based approach composes with select for free — same primitive for timers and any other concurrent operation.
• vs Java ScheduledExecutorService: Java requires a thread pool and scheduling primitives. Go uses the runtime's built-in heap of timers — much lighter.
• vs Python threading.Timer / asyncio.sleep: Python's are callback or coroutine-based. Go's are values you pass around.
• vs Unix setitimer: OS-level signals are awkward and process-wide. Go timers are per-goroutine and compose freely.

• Tickers leak if not stopped. Always defer tk.Stop() immediately after creation — forgotten tickers keep firing forever, slowly burning CPU.
• time.After in long-running loops leaks memory — each iteration allocates a new timer that lives until it fires. Use time.NewTimer + Reset in hot loops.
• Ticker drops ticks under load. If your handler is slow, you get the next tick whenever you're ready; ticks aren't queued. This is by design — prevents runaway pile-ups.
• Reset on a fired timer needs draining the channel first, otherwise you'll get the old value. Pre-Go 1.23 this was a famous footgun; modern Go fixed the semantics.
• For testability, abstract time.Now/time.NewTicker behind an interface so tests can use a fake clock (benbjohnson/clock).

• Mutex — mutual exclusion lock; one goroutine at a time.
• RWMutex — readers/writer lock; many readers OR one writer.
• WaitGroup — wait for N goroutines to finish.
• Once — guarantee a function runs exactly once across all goroutines.
• Cond — condition variable for signal/wait coordination.
• Map — concurrent map optimized for specific access patterns.
• Pool — per-P object recycler to reduce GC pressure.
• OnceFunc/OnceValue/OnceValues (Go 1.21+) — convenient lazy-initialization wrappers.

• sync.Mutex: var mu sync.Mutex; mu.Lock(); defer mu.Unlock(); /* critical section */. The zero value is an unlocked mutex — no constructor needed.
• sync.RWMutex: mu.RLock() for readers, mu.Lock() for writers. Pays off when reads vastly outnumber writes.
• sync.WaitGroup: wg.Add(1) before each goroutine, wg.Done() at end of each, wg.Wait() in the parent.
• sync.Once: once.Do(func() { /* runs exactly once */ }) — the standard idiom for lazy singleton initialization.

• Zero value usability: every sync type works straight from var x sync.Mutex — no constructors, no nil checks.
• vs Java synchronized keyword: Go locks are explicit values, not keywords on methods. More flexible (lock can be embedded, passed) but require discipline.
• vs C++ std::mutex: Very similar shape, but Go lacks C++'s RAII guards (std::lock_guard) — use defer Unlock() instead.
• vs Python threading: Python's GIL means true parallelism is rare; Go's primitives matter more because real concurrency happens.
• sync.Once is unique — most languages need an "atomic boolean flag + double-checked locking" dance. Go gives you the right answer in one method call.

• Always pair Lock/Unlock with defer immediately after Lock — guarantees release on panic or early return.
• Don't copy a Mutex after first use; go vet catches this. Always use pointer receivers on types containing mutexes.
• Lock as late as possible, unlock as early as possible — minimize the critical section.
• Choose RWMutex only with measurement — its overhead exceeds Mutex unless reads vastly outnumber writes.
• Don't mix channel and mutex synchronization on the same data — pick one model per piece of state.
• Don't reset a WaitGroup while goroutines are still using it — recreate it instead.

• API: RLock/RUnlock for readers, Lock/Unlock for writers.
• Behavior: any number of readers can hold the lock simultaneously, but a writer requires exclusive access.
• When it pays off: only when reads vastly outnumber writes (typically 100:1 or more) AND the critical section is meaningful work. For trivial sections, plain Mutex is faster.
• Writer starvation: a continuous stream of readers can starve writers — Go's implementation handles this but with some latency cost.

• API: Store, Load, LoadOrStore, LoadAndDelete, Delete, Range.
• Optimized for two patterns: (1) keys written once, read many times (caches); (2) goroutines accessing disjoint key sets.
• NOT a drop-in for map + Mutex. For write-heavy workloads, the regular map + lock is significantly faster.
• No len() and no type safety: uses any for key and value, requiring assertions.
• Range can see stale or in-flight values — not a snapshot.

• Purpose: reuse short-lived allocations to reduce GC pressure.
• API: p := sync.Pool{New: func() any { return new(Buffer) }}; buf := p.Get().(*Buffer); /* use */; p.Put(buf).
• Per-P sharding: internally has one pool per scheduler P, so contention is minimal.
• GC may evict items at any time. Unlike traditional pools, Pool is a cache, not a guarantee — items can vanish between Put and Get.
• Used in stdlib: fmt, encoding/json, net/http, bytes.Buffer internals.
• Always reset Pool items before Put — they may carry stale data from previous use.

• Pattern: hold a lock, wait for a condition to become true, get notified by another goroutine.
• API: c := sync.NewCond(&mu); goroutines call c.Wait() (releases lock, waits, re-acquires); signaler calls c.Signal() (wake one) or c.Broadcast() (wake all).
• Almost always overkill in Go — channels handle most signal/wait scenarios more cleanly. The Go team has openly discussed deprecating Cond.

• Standard idiom: var once sync.Once; var db *DB; func GetDB() *DB { once.Do(func() { db = connect() }); return db }
• The function inside Do runs exactly once across all goroutines, even under contention.
• Modern alternatives (Go 1.21+): sync.OnceFunc, sync.OnceValue, sync.OnceValues wrap the pattern in a function returning closures.

• Load — atomic read.
• Store — atomic write.
• Add — atomic add (returns the new value).
• Swap — atomic exchange (returns the old value).
• CompareAndSwap (CAS) — atomic "if value == old, replace with new" (returns success bool). The foundation of lock-free data structures.
• And/Or (Go 1.23+) — atomic bitwise operations.

var counter atomic.Int64
counter.Add(1)
v := counter.Load()
counter.Store(0)
ok := counter.CompareAndSwap(0, 100)

• vs Mutex: A Mutex can block contending goroutines and involves the scheduler. Atomics use single CPU instructions (CMPXCHG, LOCK ADD, etc.) that complete in a few nanoseconds with no kernel involvement.
• One value at a time: atomics work on a single machine word. Updating two related fields atomically still requires a mutex (or CAS on a struct pointer).
• vs Java AtomicInteger: nearly identical API and use cases. Both wrap the same underlying CPU instructions.
• vs C++ std::atomic: Go's atomics are sequentially consistent by default; C++ exposes weaker memory orderings (acquire/release/relaxed). Go gives you fewer footguns.
• vs Rust std::sync::atomic: Rust exposes the full memory ordering palette like C++. Go is intentionally simpler.

• For protecting more than one variable — use a Mutex. Atomic ops on two separate variables don't compose.
• For complex state transitions — CAS retry loops are tricky to get right. Mutex is clearer.
• For low-contention workloads — Mutex is fine and clearer to read.
• For 64-bit atomics on 32-bit ARM — alignment requirements bite. The typed API hides this; the function API doesn't.

• Mixing atomic and non-atomic access on the same variable is a data race even though one side is "atomic". The race detector catches this.
• The old function API requires alignment: a uint64 field in a struct must be 8-byte aligned. The typed API handles this automatically.
• CAS retry loops can spin forever under high contention — back off or fall to a mutex.
• atomic.Value stores any value but the type cannot change after the first Store.

• Counter increment: two goroutines both read counter=5, both write 6 → final value is 6 instead of 7.
• Map write: two goroutines write to m[k] simultaneously → runtime panic "concurrent map writes".
• Slice append: append from multiple goroutines without sync → corrupted slice header, lost values.
• Stale read: one goroutine reads a flag, the other writes — without sync, the reader may see the stale value forever due to CPU caching and compiler reordering.

• Self-deadlock: sending to an unbuffered channel with no receiver in the same goroutine.
• Forgotten close: a worker ranges over a channel that's never closed → range never exits → goroutine blocked forever.
• Lock-order inversion: goroutine A locks X then Y; goroutine B locks Y then X. Eventually they cross — both wait forever.
• Wait-without-send: goroutine waits on a channel send that never happens because the sender errored.
• WaitGroup forgot Add: wg.Wait() returns immediately because the count was 0.
• Mutex held during channel op: goroutine A holds mutex and tries to send on a channel; goroutine B is supposed to receive but first wants the mutex.

• Usage: go test -race ./..., go run -race main.go, go build -race.
• How it works: instruments memory accesses at compile time and tracks happens-before relationships at runtime.
• Output: when a race is detected, you get the goroutine IDs, stack traces of both the read and the write, and which mutexes were (or weren't) held.
• Cost: ~5–10× CPU and ~5–10× memory. Use in tests/staging, not production.
• False negatives: the detector finds races that actually happened in this run — it can't prove absence. Run your test suite many times.
• Industry standard: always run CI with -race.

• vs Java: Java has no built-in race detector; tools like ThreadSanitizer or third-party libraries are needed. Go's is part of the toolchain.
• vs C++ ThreadSanitizer: Go's race detector is built on the same TSan runtime — same engine, integrated into go test.
• vs Rust: Rust prevents most data races at compile time via the borrow checker. Go catches them at runtime via the race detector — easier to learn, less safe.
• Whole-program deadlock detection: Go's runtime detects when every goroutine is blocked and panics with fatal error: all goroutines are asleep - deadlock!. Partial deadlocks (only some goroutines stuck) need SIGQUIT or pprof to diagnose.

• Always run -race: in CI, in dev, in long-running stress tests.
• Acquire locks in a consistent order across the entire codebase to avoid inversion.
• Use channels to transfer ownership rather than locks to share data.
• Use higher-level primitives like errgroup instead of raw goroutines.
• Always have a way out: every long-running goroutine needs a context, timeout, or done channel.
• Use leak-detection tools like uber-go/goleak in tests.

• WithCancel(parent) — returns a new context plus a cancel() function. Calling cancel() closes the context's Done channel, propagating to all descendants.
• WithTimeout(parent, d) — like WithCancel but auto-cancels after duration d.
• WithDeadline(parent, t) — auto-cancels at a specific wall-clock time.
• WithValue(parent, key, value) — attaches a request-scoped value (use sparingly!).
• WithoutCancel / WithDeadlineCause / WithCancelCause (Go 1.21+) — modern variants for advanced patterns.

type Context interface {
  Deadline() (deadline time.Time, ok bool)
  Done() <-chan struct{}
  Err() error
  Value(key any) any
}

• Done() returns a channel that's closed when the context is cancelled. This is what you select on.
• Err() returns nil if not done, or context.Canceled / context.DeadlineExceeded after.
• Deadline() returns the deadline (if any) for downstream timeout calculations.
• Value() retrieves request-scoped data — use sparingly.

• Cancelling a request context cancels every downstream operation (DB queries, HTTP calls, sub-goroutines).
• Setting a 5-second timeout on a request automatically gives every nested call at most 5 seconds.
• A panic in one branch can be cleanly contained by cancelling its context.
• Forgetting to call cancel() leaks resources — always defer cancel().

• vs Java thread interrupts: Java uses Thread.interrupt() which sets a flag the thread checks. Go's context is explicit and granular — you can have multiple cancellation scopes per goroutine.
• vs .NET CancellationToken: Very similar in spirit. Both pass a token through method calls; both let you observe cancellation via a callback or channel.
• vs JS AbortController: Same idea, more recent invention. JS lacks the tree-of-cancellation propagation that Go provides automatically.
• vs Python asyncio.CancelledError: Python's cancellation is exception-based and tied to the event loop. Go's is value-based and works the same in any concurrency model.
• Just an interface: Go's context is not a special runtime feature. It's an ordinary interface with channels and mutexes inside — anyone can implement a custom Context.

• Always pass ctx as the first parameter — never store it in a struct field unless you're a long-running service.
• Always defer cancel() after creating a derived context, even if it has a timeout.
• Don't use context.WithValue for ordinary parameters — only for cross-cutting concerns like request ID, user, tracing.
• Use typed keys for WithValue: type ctxKey string; const userKey ctxKey = "user" — prevents collisions.
• In long-running goroutines, watch ctx.Done() in a select alongside your work channel.
• Don't pass nil contexts — use context.TODO() if you genuinely don't have one.
• Tests: use context.Background() with WithTimeout for deterministic timeouts.