Go.CodeCompared.To/TypeScript

TypeScript needs no package main, no import, and no func main — top-level statements run in source order. console.log is the everyday equivalent of fmt.Println and adds a trailing newline the same way. The semicolon is optional in TypeScript, but most style guides keep it.

Unlike Go, TypeScript does not produce a self-contained native binary — it transpiles to JavaScript that a runtime such as Node.js executes. tsx compiles and runs in one step like go run, while tsc emits .js files like go build emits a binary. The type checker is a separate step from execution, and a program with type errors still runs.

TypeScript has no Printf verbs. Template literals use backticks with ${...} to interpolate any expression — the closest analogue to building a string before printing it. Numeric formatting is done with methods such as toFixed(1) rather than a %.1f verb.

Comment syntax is identical to Go: // and /* ... */. TypeScript adds the /** ... */ JSDoc convention, which editors surface as hover documentation and which can even supply types in plain JavaScript files — there is no Go equivalent that the toolchain reads at edit time.

TypeScript writes the type after the name with a colon (explicit: number), the reverse of Go's var explicit int. Just like Go's :=, an initializer lets the type be inferred. Prefer const (single assignment) over let (reassignable); var exists but is function-scoped and discouraged.

TypeScript's enum auto-numbers its members from 0, exactly like Go's iota pattern, but it is a real named type with reverse mapping (Direction[0] === "North"). For plain compile-time constants, TypeScript uses const; unlike Go there is no block form, so each constant is its own const statement.

TypeScript collapses Go's whole integer and floating-point family — int, int64, float64, and the rest — into a single number (an IEEE-754 double). There is no separate integer type and no overflow wrapping; bool becomes boolean and string keeps its name. For 64-bit integers beyond 2^53, TypeScript offers a distinct bigint type.

Go gives every variable a zero value (0, "", false, nil) automatically. TypeScript has no zero values: under strictNullChecks you must initialize a variable, and the absence of a value is its own concern — undefined (never assigned) and null (deliberately empty) are distinct types you opt into with a union like string | null. This is what eliminates Go's "forgot to check for nil" class of bug at compile time.

Go requires an explicit conversion between every numeric type (float64(whole)); TypeScript has only one numeric type, so int-to-float conversions simply do not exist. Converting a number to a string uses String(value) or value.toString() rather than strconv.Itoa. Note these are runtime conversions — the TypeScript as keyword is a compile-time type assertion that does nothing at runtime.

Go strings are immutable byte slices: len counts bytes and indexing yields a byte. TypeScript strings are sequences of UTF-16 code units: .length counts units and indexing returns a single-character string, not a numeric code. Neither counts user-perceived characters for astral-plane glyphs, but the everyday failure modes differ — bytes in Go, surrogate pairs in TypeScript.

Where Go builds a string with fmt.Sprintf and % verbs, TypeScript embeds expressions directly inside a backtick template literal with ${...}. Any expression is allowed, not just variables, and no format verb or type matching is needed — values are converted to strings automatically.

Go keeps string operations in the strings package as free functions that take the string as an argument; TypeScript hangs them off the string value as methods (phrase.trim()). Note replace swaps only the first match by default — pass a regular expression with the g flag to replace all, the equivalent of Go's strings.ReplaceAll.

The operations mirror Go almost exactly, but the spelling moves onto the value: csv.split(",") instead of strings.Split(csv, ","), and parts.join(" | ") instead of strings.Join(parts, " | "). The result of split is a typed string[] array.

Ranging over a Go string decodes UTF-8 into runes and gives you a byte offset plus the rune. TypeScript's for...of over a string iterates by Unicode code point — so é arrives as one item even though it spans two UTF-16 units — which is closer to Go's rune iteration than indexing by [i] would be. There is no built-in byte offset; use .entries() if you need an index.

Go gives you a sized integer for every need (int8, uint32, int64, …) and distinguishes integers from floats. TypeScript has a single number, a 64-bit float, so integers are exact only up to 2^53 and there is no overflow wrapping — a value simply loses precision. The same IEEE-754 rounding that makes 0.1 + 0.2 imprecise in Go's float64 applies to every TypeScript number.

This is a classic Go-to-TypeScript trap: 7 / 2 is 3 in Go because both operands are integers, but 3.5 in TypeScript because every number is a float. To get Go's integer division you must truncate explicitly with Math.trunc (toward zero) or Math.floor (toward negative infinity). The % operator works on floats too, unlike Go where it is integer-only.

Go's math package and TypeScript's built-in Math object cover the same ground with lowercase-first method names instead of Go's exported capitals. TypeScript also has an exponentiation operator, 2 ** 10, with no Go equivalent. Math.max accepts any number of arguments, where Go's math.Max takes exactly two.

Go signals a parse failure with a second error return that you must check. TypeScript instead returns the special value NaN, which you test for with Number.isNaN — there is no error to ignore, but also nothing forcing you to check. Always pass the radix 10 to parseInt to avoid surprises with strings like "0x10".

A TypeScript array is the everyday equivalent of a Go slice: growable, reference-like, and written number[] (or the generic form Array<string>). There is no separate fixed-length array type as in Go's [3]int; for that, TypeScript uses a tuple type, [number, number, number]. Length is a property, numbers.length, not a function.

Go's append returns a new (possibly reallocated) slice that you must reassign — a common source of bugs when the return value is dropped. TypeScript's push mutates the array in place and returns the new length, so even a const array can grow: const freezes the binding, not the contents. To copy rather than mutate, spread into a new array: [...queue, "fourth"].

Go's for index, value := range gives you both the index and the element. TypeScript offers two idioms: forEach((value, index) => ...) — note the argument order is reversed from Go — or a for...of loop over colors.entries() when you need break or continue, which a callback cannot provide.

TypeScript's slice(start, end) matches Go's digits[start:end] — end-exclusive, with an optional end. The crucial difference: Go's slice expression shares the underlying array, so writes through one slice can be seen by another, whereas Array.slice always returns a shallow copy. There is no aliasing surprise in TypeScript.

Go has no map/filter/reduce in its standard library philosophy — you write the loop by hand. TypeScript inherits JavaScript's chainable array methods, so transformations read as a pipeline. Each returns a new array (or value) without mutating the original, and the element type flows through so the compiler knows doubled is a number[].

Go's sort.Slice takes a less function returning a bool. TypeScript's Array.sort wants a comparator returning a number: negative, zero, or positive. For numbers, left - right ascends. Beware: sort with no comparator sorts as strings (so [10, 9] becomes [10, 9]), and it mutates the array in place like Go.

TypeScript's Map is the direct counterpart to Go's map: any key type, insertion-ordered, sized by .size. You read and write with .get/.set rather than bracket indexing. A plain object ({ alice: 30 }) also works as a string-keyed dictionary, but Map preserves insertion order, allows non-string keys, and will not collide with prototype properties.

Go's comma-ok idiom (value, ok := m[key]) distinguishes "key absent" from "key present with zero value". TypeScript's Map.has(key) answers presence directly, and .get returns undefined for a missing key — which, under strictNullChecks, the compiler forces you to handle. There is no silent zero value masquerading as a real entry.

Go deliberately randomizes map iteration order, so reproducible output means collecting and sorting the keys first. A TypeScript Map iterates in insertion order, deterministically, and a for...of loop destructures each [key, value] entry directly — no separate key slice needed. This predictability is one of Map's advantages over Go's intentional shuffle.

Go has no set type, so the idiom is a map[T]struct{} where the empty struct uses no memory. TypeScript ships a real Set: add, has, delete, size, and iteration in insertion order. It is the natural choice for de-duplication, and new Set(array) followed by [...set] is the standard way to unique an array.

The structure is the same, with one syntactic flip: TypeScript requires parentheses around the condition, where Go forbids them. Beware truthiness — TypeScript treats 0, "", null, undefined, and NaN as falsy, so if (score) is not the same as if (score !== 0). Go has no such coercion: conditions must be genuine booleans.

Go cases do not fall through and can list several values in one case. TypeScript inherits C-style fall-through, so each case needs an explicit break, and matching multiple values means stacking empty case labels. Forgetting a break is a real bug class in TypeScript that simply cannot occur in Go.

Go has exactly one loop keyword, for, that doubles as a while loop and an infinite loop. TypeScript keeps the C family's separate while and do...while alongside the three-clause for. Use let for the loop variable so each iteration's binding is block-scoped, which matters when you capture it in a closure.

Go deliberately omits the ternary operator, forcing an if/else. TypeScript keeps condition ? a : b, which makes conditional initialization a one-liner. It also adds the nullish-coalescing operator ?? that supplies a fallback only when the left side is null or undefined (not merely falsy) — handy for default values where Go would check nil explicitly.

A TypeScript function declares parameter types after each name and the return type after the parameter list, mirroring Go's func add(left int) int with colons. Return types are usually inferred, so they are optional. The arrow form (const subtract = (...) => ...) is a concise expression-bodied function with no Go equivalent, ubiquitous for callbacks.

Go returns multiple values natively. TypeScript has no such thing, so the idiom is to return a tuple type [number, number] and destructure it at the call site with const [a, b] = .... For more than two or three values, returning a named object ({ quotient, remainder }) reads better and survives reordering.

Both languages collect trailing arguments into a slice/array. Go writes numbers ...int and the parameter has type []int; TypeScript writes ...numbers: number[]. To spread an existing array into the call, Go uses total(values...) and TypeScript uses total(...values) — the dots simply move to the front.

Go has no default arguments — the common workaround is a sentinel zero value or an options struct. TypeScript supports real defaults (greeting: string = "Hello") and optional parameters marked with ?, whose type becomes string | undefined. Optional parameters must come after required ones, just like default-valued ones.

Closures capture variables by reference in both languages, and the captured state outlives the enclosing call. The function-type syntax differs: Go writes func() int, TypeScript writes () => number. The arrow function also captures this lexically, which matters inside classes — a frequent source of bugs that the arrow form quietly fixes.

Passing functions as first-class values works the same way; the parameter type is just spelled differently — Go's func(int) int versus TypeScript's (value: number) => number. Because the callback's parameter type is known from apply's signature, TypeScript infers n as a number at the call site, so you rarely annotate inline arrow functions.

Go's struct is a plain value type; TypeScript's class bundles fields and methods together and is instantiated with new. The public x: number parameter-property shorthand declares and assigns the field in one stroke — much terser than Go's separate field list. For pure data with no behavior, a TypeScript interface or type is closer to a Go struct than a class is (see the Interfaces section).

Go attaches methods to a type with a receiver outside the struct (func (r Rectangle) Area()). TypeScript declares methods inside the class body and accesses fields through this rather than a named receiver. There is no value-vs-pointer-receiver distinction: objects are always handled by reference, so a method can freely mutate the instance.

Go has no inheritance; it composes behavior by embedding a struct, which promotes the inner type's fields and methods. TypeScript has true single inheritance with extends and super, so Dog genuinely is an Animal and can override describe. The Go embedding model is closer to "has-a with forwarding"; the TypeScript model is classical "is-a".

Go controls visibility by capitalization at the package boundary — exported names start uppercase. TypeScript uses explicit public, private, and protected modifiers enforced at compile time within the class. (For true runtime privacy, JavaScript's #field syntax is also available.) The get keyword defines a computed property accessed without parentheses, which Go has no equivalent for.

This is the most reassuring parallel for a Go developer: TypeScript interfaces are structural, exactly like Go's. A type satisfies Shape by having the right methods, not by declaring a relationship. The implements Shape clause is optional documentation that makes the compiler check the match early; remove it and Circle still works as a Shape wherever its shape fits.

Go interfaces describe method sets only; data is described by structs. TypeScript interfaces describe the shape of any value — including plain-data fields — so a bare object literal { name, age } satisfies User with no class or constructor. This is the everyday way to type function arguments and return values; reach for a class only when you need methods or instance state.

Go's any (an alias for the empty interface) holds any value and is unpacked with a type switch. TypeScript has two counterparts: any turns type-checking off for that value (escape hatch — avoid it), while unknown is the safe version that forces you to narrow with typeof before use, much as Go forces a type assertion. Prefer unknown; it is the honest equivalent of Go's any.

Go's comma-ok assertion value.(string) checks the dynamic type at runtime and reports success. TypeScript's typeof/instanceof guards do the same and narrow the variable's static type inside the block. Beware the as keyword: it is a pure compile-time claim with no runtime check — if you are wrong, the error surfaces later, unlike Go's failed assertion which panics or returns false immediately.

Go cannot say "this value is an int or a string" except through the untyped any. TypeScript's union type number | string expresses exactly that, and the compiler then requires you to handle every member before using member-specific operations. After the typeof check returns, TypeScript knows the remaining type is string with no further test — narrowing the union as control flow proceeds.

Go's named string type Status documents intent but does not restrict the set of values — any string literal still satisfies it. TypeScript's literal union "active" | "inactive" makes the exact allowed values part of the type, so a typo is a compile error. This is one of the genuinely new powers TypeScript offers a Go developer: types built from specific values, not just shapes.

Go models a closed set of variants with a sealed interface and a type switch. TypeScript's idiom is a discriminated union: each member carries a literal kind tag, and switching on that tag narrows shape to the exact variant in each branch — shape.radius is only accessible after case "circle". Crucially, the compiler checks exhaustiveness: add a third shape and forget a case, and it flags the gap, something Go's type switch cannot guarantee.

Generics arrived in Go 1.18 with square brackets ([T any]); TypeScript uses angle brackets (<T>) and has had them from the start. In both, the type parameter is inferred from the argument, so callers rarely write it. TypeScript's any constraint is simply the absence of a constraint — an unconstrained <T> accepts anything.

Go constrains a type parameter with an interface that lists permitted underlying types (~int | ~float64). TypeScript constrains with T extends SomeShape, meaning "any type assignable to this shape". Note the philosophical difference: Go's numeric constraints exist because operators like + are not methods, whereas TypeScript constraints are about structure — here, anything with a length property, be it a string or an array.

Generic structs and generic classes line up closely: Stack[T] versus Stack<T>, and the type parameter threads through the methods. One safety difference stands out — TypeScript's Array.pop returns T | undefined because the stack might be empty, and strictNullChecks makes you confront that, whereas Go's slice indexing would panic at runtime on an empty stack.

This is the deepest cultural gap between the two languages. Go treats errors as ordinary return values you must inspect; TypeScript (like most languages) throws exceptions that unwind the stack until a try/catch catches them. There is no (value, error) tuple and nothing forcing a caller to handle failure — an uncaught throw crashes the program. The compiler also cannot tell you which functions might throw, unlike Go's explicit error return.

A Go custom error is any type implementing the Error() string method. A TypeScript custom error extends the built-in Error class, carrying extra fields and a name. In the catch block the caught value is typed unknown (or any), so you narrow it with instanceof — the TypeScript equivalent of Go's errors.As for recovering a specific error type.

Go wraps errors with %w and unwraps with errors.Unwrap. Modern TypeScript mirrors this with the { cause } option on Error, readable back via error.cause. For cleanup, Go uses defer; TypeScript uses a finally block that runs whether or not an exception was thrown — the same guarantee, attached to the try rather than scheduled per call.

Go separates errors (expected, returned as values) from panics (unexpected, recovered only via defer/recover). TypeScript makes no such distinction — every failure is a thrown value caught by try/catch, so the same mechanism handles both a validation failure and a programming bug. There is nothing like Go's deliberate two-tier model; discipline about what you throw replaces it.

Go achieves concurrency with goroutines — cheap threads scheduled across CPU cores by the runtime. TypeScript (on Node.js) is single-threaded with an event loop: async functions return a Promise<T> and await suspends without blocking the thread. This is concurrency without parallelism — many operations in flight, but one line of code running at a time. There is no go keyword and no shared-memory race condition to guard against.

A Go channel is a typed conduit between goroutines: one side sends, the other receives and blocks until a value arrives. A TypeScript Promise is a one-shot future — it resolves exactly once with a value, and await reads it. A channel can carry many values over time and synchronizes two running goroutines; a promise carries a single eventual result with no second thread involved.

Go coordinates a fleet of goroutines with a sync.WaitGroup — increment, Done, and Wait. TypeScript's Promise.all does the equivalent in one call: it takes an array of promises and resolves to an array of their results, in order, once all complete (rejecting immediately if any throws). It is the everyday tool for running independent async operations concurrently and collecting their outputs.

Go's select waits on several channel operations and proceeds with whichever is ready first. TypeScript's Promise.race settles as soon as the first promise in the array settles, ignoring the rest — the closest analogue for "take whichever finishes first". Use Promise.any when you want the first successful result and are willing to ignore rejections.

Go imports whole packages by path and qualifies every use with the package name (strings.ToUpper). TypeScript imports named bindings out of a module with import { x } from "...", bringing the names directly into scope, plus an optional default export. Because this example relies on Node and npm modules that the in-browser runtime cannot load, it is marked non-runnable.

Go decides export visibility by capitalization across a whole package directory. TypeScript decides it per file (each file is a module) with an explicit export keyword on whatever should be importable; everything else stays module-private. Names without export are the equivalent of Go's lowercase identifiers. This example is multi-file and uses module syntax, so it is non-runnable in the browser sandbox.

Go can alias an import (m "math") to shorten or disambiguate a package name. TypeScript offers two related tools: import * as math gathers every export of a module into one namespace object (much like Go's package-qualified access), and import { double as twice } renames an individual binding. As a multi-file module example, it is marked non-runnable here.