Go.CodeCompared.To/JavaScript

There is no compile step, so nothing is checked before it runs — including whether a function exists. console.log takes several arguments and separates them with spaces, so it is closer to fmt.Println than to fmt.Print, and it writes to stdout while console.error writes to stderr. An unused import is a compile error in Go and does not exist as a concept here; an unused variable is likewise only a linter's opinion.

Width and precision are method calls applied to the value before it reaches the string: toFixed, padStart, toLocaleString. There is no %v and no %+v: console.log of an object prints an engine-specific rendering that differs between Node and browsers, so anything you actually depend on goes through JSON.stringify. There is also no Stringer interface that console.log consults — it ignores toString for objects, which surprises everyone once.

Adding a number to a string is a defined operation rather than a type mismatch, and a misspelled method is a TypeError found only if that branch runs. Two consequences for a Go author: your test coverage is now the type checker, and TypeScript is how the ecosystem gets some of it back — the same language with a checker on top, erased before execution. If you are shipping a library the JavaScript world consumes, shipping .d.ts type declarations alongside it is the equivalent of exporting a documented API.

Promise.all is the shape a WaitGroup becomes, and it is not the same thing. Three goroutines genuinely run at once on separate cores; three promises interleave on one thread, so they overlap only where they wait on I/O. CPU work does not overlap at all. The mental substitution to make: stop asking "how many goroutines" and start asking "how many things are waiting on the network", because that is the only axis on which JavaScript concurrency exists.

Read the order the two columns printed in: Go says main continues first, JavaScript says it last. That inversion is the whole row. In a browser the page stops responding to clicks and stops painting; in Node every other request waits. There is no preemption, because there is nothing to preempt to. This is the single most important operational difference for anyone porting a Go service to Node: a request handler that does real computation is a production incident, and the fix is to move the work off the thread entirely — a Web Worker, a worker_threads pool, a queue, or (the reason the last section of this page exists) a WASM module.

What it gives you is the unbuffered, one-producer/one-consumer case with backpressure, and return from the generator is close. What it does not give you is any of the rest: no buffered channels, no multiple senders, no select, and no fan-in. A real queue with several producers is a small class you write around an array and a list of waiting resolvers, or a library (p-queue, async). Note also that a generator is pull-driven where a channel is push-driven, so a producer that must run ahead of its consumer needs an explicit buffer.

First, the loser is not cancelled — it keeps running, and if it rejects afterwards you get an unhandled rejection from work whose result you discarded. Second, there is no default clause, so there is no non-blocking poll. Third, a promise settles once, where a channel yields repeatedly, so select in a loop has no counterpart at all — that becomes an event emitter or an async iterator. Promise.any is the "first success" variant, which select has no equivalent of.

A JavaScript function runs to completion before any other code runs (run-to-completion semantics), so total++ can never interleave and there is no torn read to protect against. What replaces the concern is logical races across await points: an await is a yield, so state you read before it may have changed by the time you resume, and two overlapping requests can interleave between awaits. The discipline shifts from "protect the memory" to "re-check your assumptions after every await".

A goroutine shares the heap, which is why sync exists and why -race is worth running. A worker shares nothing: messages are structured-cloned across the boundary, so passing a large array copies it, and functions and class instances do not survive the trip at all. The exceptions are ArrayBuffer (transferable — moved, not copied) and SharedArrayBuffer plus Atomics, which is real shared memory and is gated behind cross-origin isolation headers. Design for message passing with coarse messages, not for shared state.

The mapping is close — ctx.Done() is signal.aborted, ctx.Err() is signal.reason, context.WithTimeout is a timer that calls abort. What is missing is the convention: Go's community agreed that ctx is the first parameter of anything that blocks, so cancellation composes everywhere. In JavaScript only some APIs accept a signal — fetch does, setTimeout does not — and nothing enforces the checking, so a loop that never looks at it simply runs to completion. Values-on-a-context has no equivalent at all.

The shape above is the idiomatic hand-rolled version: N runner promises pulling from a shared index, which is exactly a worker pool with the channel replaced by a cursor. In practice most teams reach for p-limit or p-map from npm rather than writing it. Remember what the limit is for: not CPU parallelism, which does not exist here, but bounding how many outbound requests or file handles are in flight at once.

That is the biggest loss coming from Go, and it has three consequences worth internalising. Nothing warns you about an unhandled failure — there is no unused-value lint and no errcheck. Any expression can throw, including a property access on undefined, so a try block is about a region of code rather than about a specific call. And you can throw anything at all — a string, a number, undefined — so a catch must not assume it received an Error. The nearest thing to if err != nil as a house style is returning { ok, value, error } by convention, which some codebases do and most do not.

The mapping is closer than it looks, with two gaps. There is no errors.As that walks an arbitrarily deep chain — you follow .cause yourself — and instanceof fails across realms, so an error from a worker or an iframe is not instanceof your class; library code often compares error.name instead. Also note that error.cause is not printed by default when an error surfaces uncaught in Node, so a wrapped error can reach a log with its most useful half missing.

A promise that rejects with nothing attached becomes an unhandled rejection. Node has terminated the process on one since v15; a browser logs to the console and carries on. The half that catches people is the timing: the handler must be attached in the same tick, so const p = doWork(); await something(); p.catch(...) is already too late. The habit to build is that every promise is either awaited inside a try or given a .catch at the moment it is created — there is no supervisor and no recover to fall back on.

So catch is not recover: catching is normal, expected and cheap, and there is no distinction between "recoverable" and "the program is broken". The deferred-closure dance that turns a panic into a returned error has no counterpart because there is no error return to assign to. finally is the closest thing to defer — it runs on every exit path from the block — but it is per-block rather than per-function and does not stack in LIFO order.

Three differences. finally is tied to a block rather than to the function, so cleanup has to wrap the work rather than sit next to the acquisition. Several defers stack and unwind in LIFO order; nested try/finally blocks are how you get that, and it reads worse each time. And defer's arguments are evaluated immediately while the call is deferred, which has no analogue at all. There is no using-style block and no destructor: FinalizationRegistry exists and the specification says it may never call you.

A Go const is a compile-time value, restricted to numbers, strings and booleans, and it has no address. A JavaScript const only stops the binding being reassigned: const numbers still accepts push, and there is no compile-time constant concept at all. Use const by default anyway — it is the linter default and the idiomatic choice — but read it as "this name will not be reassigned", never as "this value cannot change". var exists, is function-scoped rather than block-scoped, and should never be written.

So there is no "" for a missing string, no 0 for a missing number and no usable-empty for a missing struct — reading an unset property gives undefined, and undefined + 1 is NaN rather than 1. That is the sharpest practical difference: a missing field in Go quietly behaves like an empty one, and in JavaScript it quietly poisons arithmetic instead. Default parameter values and ?? are how the ecosystem fills the gap, and they only fire on null/undefined — never on 0 or "".

So two identical arrays are unequal, and the usual workaround is JSON.stringify on both — which is wrong for key order and for anything JSON cannot represent; a real deep-equal comes from a library or from node:assert. The struct row has no counterpart at all: there is no value type, so {x:1,y:2} === {x:1,y:2} is always false. And ==, the two-character version, converts its operands before comparing; treat it the way you treat unsafe — the one idiomatic use is value != null, which tests for exactly null and undefined.

typeof covers the seven primitives; instanceof covers classes and fails across realms, which is why Array.isArray exists. typeof null is "object" and typeof [] is "object", both permanent warts. What is genuinely missing is the binding half: a type switch gives you typed narrowed to the case's type, and here nothing changes about what you may call — nothing stops you calling a string method in the integer branch. TypeScript restores exactly that, and its narrowing understands all three mechanisms above.

Strings rather than integers, because they survive JSON.stringify and read well in a debugger. What is lost is the type: a function taking a "Status" will accept any string at all, and a typo is undefined rather than a compile error. Object.freeze is shallow and, outside strict mode, ignores writes silently rather than throwing. TypeScript's union of string literals ("active" | "retired") restores the checking, which is much of why a Go author writing a library for this ecosystem ends up shipping type declarations.

Division always produces a float, so integer division is Math.trunc(a / b); use Math.floor when you want Go's behaviour for negative numerators, which differ. Nothing wraps, because nothing has a width — uint8 arithmetic is just arithmetic. Integers are exact only to 2⁵³ (Number.MAX_SAFE_INTEGER), past which additions silently round rather than wrapping, which is a quieter failure than Go's. Fixed-width arithmetic is available through the typed arrays (Uint8Array, Int32Array), which are also what you share with a WASM module.

A BigInt is arbitrary-precision and integral, and it deliberately refuses to mix with number in arithmetic — a rare piece of strictness. It also cannot be JSON.stringifyd without a custom replacer, and Math.* will not accept it. The practical rule for an API a JavaScript client consumes: send 64-bit identifiers as strings. A snowflake ID or a database primary key that arrives as a JSON number is silently rounded by JSON.parse before your code ever sees it, and no error is raised anywhere.

Go's untyped constants are arbitrary-precision and folded at compile time, so a literal 0.1 + 0.2 is exactly 0.3 and only becomes a float64 when it is assigned or passed. JavaScript has no constant folding of that kind, so the literal expression gives the same wrong answer as the variables. That difference bites when porting a numeric algorithm: the Go version may be quietly more accurate than the arithmetic it appears to describe. The rest is printing — JavaScript has no float/integer distinction to preserve, so 1.0 prints as 1, and toFixed returns a string and rounds half-away-from-zero where Go's %.2f rounds half-to-even.

A Go string is UTF-8 bytes: len("naïve") is 6 and len("🦀") is 4. A JavaScript string is UTF-16 code units: "naïve".length is 5 and "🦀".length is 2. Ranging over a Go string yields runes with byte offsets; for...of yields code points with no index at all, which is why the example counts by hand. There is no rune type and no byte type — for bytes you want a TextEncoder and a Uint8Array. Grapheme clusters need Intl.Segmenter in both worlds.

The names are guessable: TrimSpace is trim, Contains is includes, HasPrefix is startsWith, Index is indexOf. The one real trap is replace: strings.Replace takes a count and ReplaceAll replaces everything, while JavaScript's replace with a string argument replaces only the first occurrence — use replaceAll. Strings are immutable in both, so there is no strings.Builder; engines optimise += internally and the array-plus-join idiom is the explicit version.

What it does not do is strip indentation — a multi-line template keeps whatever leading whitespace the source had, which is why dedent libraries exist and why the example above is left-aligned. String.raw is the tagged-template form that leaves backslashes alone, so it is the closest thing to a Go backquoted string. Tagged templates in general have no Go counterpart at all: sql\`SELECT ...\` passes the pieces and the values to a function, which is how the ecosystem builds safe query and CSS builders.

🚨 The engine is the important difference. Go's RE2 guarantees linear time and therefore refuses backreferences and lookaround; JavaScript's backtracking engine offers both and offers no guarantee, so a hostile pattern or input is a genuine denial-of-service risk. Flags go after the closing slash: g for every match (the opposite default from ReplaceAllString, which is why replace needs it), i, u for correct Unicode handling, s, m, y. A g regex object carries mutable state in lastIndex, so reusing one across test calls gives alternating answers.

Three consequences. There is no cap and nothing to preallocate: new Array(1000) creates a thousand holes, not a thousand slots, and holes behave badly (skipped by forEach, counted by length). Reading past the end gives undefined rather than panicking, so an off-by-one is silent. And slice copies where Go's slicing aliases the same backing array — which removes the whole family of "my subslice mutated the original" bugs, and means the trick of reusing capacity is gone.

The comma-ok idiom splits into two calls: get returns undefined for a missing key, and has answers the membership question — necessary, because a key whose value is undefined is indistinguishable otherwise. The ordering difference is the one to internalise: Go deliberately randomises map iteration order, while a Map preserves insertion order and a plain object mostly does (integer-like keys sort first). So code that accidentally depends on iteration order will pass here and fail there. A plain object also coerces every key to a string and carries prototype properties, which is why Object.create(null) exists.

Go got generics in 1.18 and slices/maps packages after, but a hand-written loop is still preferred for clarity. JavaScript's chain is universal, and it is eager: each step builds a whole new array, so a three-step chain over a million elements makes two intermediates and does three passes. For a large source that is the reason to write the loop after all — or to use a generator, since array methods have no lazy form. There is no sum: reduce with an explicit initial value covers it, and omitting the initial value on an empty array throws.

So [10, 9, 100].sort() gives [10, 100, 9]. Always pass a comparator for numbers — it returns a negative number, zero or a positive one, exactly the contract slices.SortFunc uses. sort also mutates in place and returns the same array, so a chain silently modifies the original; toSorted() (ES2023) is the non-mutating version, along with toReversed, toSpliced and with. Sorting has been stable since ES2019, where Go's slices.Sort is not (use SortStableFunc).

JavaScript has no such split. An array is one object passed by reference, so push and an index assignment are equally visible to the caller — which is simpler to reason about and removes the "why did my append vanish" question entirely. What comes back in its place is the need to copy defensively when handing an array to code you do not trust: [...numbers] or structuredClone for a deep copy. There is no array-value type to fall back on the way a Go [3]int array copies.

So the "should this be a pointer receiver?" question, and the whole discipline of knowing when you are mutating a copy, simply disappears — replaced by its mirror image: you are always mutating the shared one, and copying is the thing you must remember. { ...first } is a shallow copy (nested objects are still shared) and structuredClone(first) is a deep one. There is no value type of any kind, so nothing behaves like a Go array or a struct field embedded by value.

The pointer-versus-value receiver distinction has no counterpart — every method can mutate, because there is nothing but references. Private fields exist now, marked #, and are genuinely private; the lowercase-means-unexported convention has no equivalent, since exports are per-file rather than per-package. Two things to watch: a method pulled off its object loses this (pass () => account.deposit(1) or account.deposit.bind(account)), and there is no way to add a method to a type you do not own without touching its prototype globally.

The behaviour looks the same and the semantics differ: a Post genuinely is a Timestamps here, satisfies instanceof, and can only extend one thing. Go's embedding is composition with syntactic promotion, and you can embed several types. The closer analogue for multiple embedding is a mixin — Object.assign(Post.prototype, timestampBehaviour) — which is what libraries do, at the cost of the conflict detection Go gives you (ambiguous promoted names are a compile error; Object.assign silently takes the last one).

JavaScript has a real constructor that runs on every new, so validation has a place the caller cannot skip. The price is that it can only throw, never return an error value or null — a constructor's return value is ignored unless it is an object. So the (value, error) pair becomes either a throwing constructor or a static factory that returns null, as above. A static factory is also the way to get several named ways of building the same type, which Go gets from having several NewX functions.

A get accessor means rectangle.area is a function call with no syntactic hint, which is convenient and occasionally alarming — a property read can throw, can be slow, and can have side effects. The same mechanism is available dynamically through Object.defineProperty and, more aggressively, through a Proxy, which can intercept any property access on an object; that is how reactive frameworks like Vue track dependencies. Nothing in Go corresponds to either.

Where they part is when. Go checks at compile time, so a missing method is an error at the assignment and the interface is a real type you can name. JavaScript checks at the instant of the call, so a missing method is a TypeError in production and there is nothing to name — the "interface" lives in your head or in a comment. Two things follow: the small-interface discipline Go teaches (io.Reader, one method) transfers perfectly as a design habit, and TypeScript's interface is genuinely the same idea as Go's, checked at compile time and erased at run time.

The comma-ok assertion (value.(string)) becomes a typeof test, and the panicking form (value.(string) without ok) has no counterpart — there is no cast that can fail, because there is no cast. What this changes in practice is where you validate: a Go program can trust a typed parameter and check only at the edges, while a JavaScript library that accepts anything either validates every public entry point or documents the shape and hopes. Runtime schema validators (Zod, Valibot) exist for exactly this, and they are what an encoding/json unmarshal into a struct does for free.

The last line is the point: sum(["a", "b"]) returns "0ab", silently, because + is defined for strings and the initial value is a number. No constraint could have prevented it, because there are no types to constrain. What replaces a type parameter is documentation, a runtime guard, or TypeScript — where the generic syntax is close enough to Go's to feel familiar, including constraints (<T extends number>). If you are porting a generic Go package, the type parameters are usually the part worth preserving in the .d.ts.

There is no equivalent, because there is no build. The nearest thing is a runtime guard as above, which costs a check and fires only when the code path runs — or TypeScript's satisfies operator, which is the direct analogue and is checked before you ship. This is worth knowing if you are publishing a package: the JavaScript ecosystem's answer to "does this still fit the contract" is a test suite plus type declarations, and there is no third option.

The array form is positional and terse, and it is what hooks-style APIs use. The object form gives the parts names, survives reordering, and is what most codebases prefer for more than two values — it is also, not coincidentally, the shape a Go author would reach for a named struct to express. Destructuring works in parameter lists too, and carries default values (const { port = 5432 } = options), which is the substitute for Go's absent default arguments.

Both languages also had the same famous bug: a closure created in a loop capturing the shared loop variable. JavaScript fixed it by giving let a fresh binding per iteration (so var in a loop is still wrong and let is right), and Go fixed it in 1.22 by scoping for variables per iteration — before that you wrote index := index. Two things to keep: the C-style for (var ...) form still has the old behaviour, and a closure held by an event handler keeps everything it captured alive, which is the shape of most JavaScript memory leaks.

The JavaScript rest parameter gives you a real array with all the array methods, and the spread operator works in array literals ([...first, ...second]) and object literals ({ ...defaults, ...overrides }) as well as in calls — neither of which Go's ... can do. Arity is never checked in either direction: extra arguments are ignored and missing ones become undefined, where Go would refuse to compile.

A JavaScript function is also an object: it has a length (declared arity), a name, and you can attach your own properties to it. That is how memoisation caches and framework hooks are sometimes bolted on. Two things Go has that this does not: a declared function type (type Transform func(int) int) that documents the contract and is checked, and methods as first-class values with a bound receiver — account.Deposit in Go is a bound method value, while account.deposit in JavaScript is an unbound function that has lost this.

Neither is a zero value, so a missing number is not 0 and a missing string is not "". ?? and ?. treat both alike, which is what you want, and value != null is the idiomatic test for "either" — the one place the loose operator is correct. The habit worth forming: never write undefined yourself. Use null for a deliberate empty and let undefined mean "absent", so the distinction carries information instead of noise.

That entire category is gone. There is no boxing of a value into an interface, so null is null and there is nothing for it to be wrapped in. It is worth naming precisely because a Go author carries a defensive habit — the careful if problem != nil { return problem } dance in the anchor column — that has nothing to defend against here. What replaces it is the opposite worry: null and undefined are two things, so a check for one may miss the other.

An unset variable is undefined, and every operation on it throws. So the Go habit of declaring var numbers []int and appending becomes "initialise it to [] first", and the ?. operator is what saves a read from an unset value. The one thing that transfers is the API advice: return an empty array rather than null or undefined, for exactly the reason Go returns a nil slice — so the caller can loop over it without checking.

A wrong type is an UnmarshalTypeError in Go and a silent "36" here — a string flowing on into arithmetic to become NaN three functions later. There are no struct tags, no omitempty and no field mapping: the keys are the keys. So validation at the boundary is your job, done by hand or by a schema library (Zod, Valibot, Ajv), and it is the single most valuable habit to carry over. Note also what JSON.stringify silently drops: undefined values, functions and symbols vanish, NaN and Infinity become null, a BigInt throws, and a cycle throws.

Go into a typed int64 field is exact; Go into map[string]any gives you a float64 and the same rounding JavaScript has. JSON.parse has no typed target at all, so the value is rounded before your code runs and no error is raised anywhere — the ID you log is not the ID that was sent. There is no reviver hook that sees the raw text of a number either. The only reliable fix is on the wire: serialise 64-bit identifiers as strings, which is why so many APIs do.

toJSON is the hook JSON.stringify consults, and it is the closest thing to MarshalJSON — it decides the shape, which covers renaming, omitting and computing. Without it, every own enumerable property is serialised, including the one you meant to keep private, which is a real leak vector when an internal object reaches a response body. There is no omitempty: an explicit undefined value is dropped and a null is kept, which is the closest accident to it.

Everything is private until exported, which is Capitalised by another means and rather more precise. Two complications Go does not have: there are two module systems in the wild — ESM (import/export, the standard) and CommonJS (require, Node's original) — declared per package in package.json, and interop between them is the most tedious part of Node work. And imports are not free: everything imported is bundled and shipped to the browser, which is why tree-shaking exists and why an unused import costs kilobytes rather than a compile error.

npm installs and runs scripts; it does not build, test, format, lint, vet or document — each is a separate dependency you choose and keep in step, which is why a new JavaScript project starts with more decisions than go mod init. Go's minimal version selection makes a build reproducible without a lockfile; npm resolves the highest version matching a caret range, so package-lock.json must be committed and CI must run npm ci. And there is no static binary: the deployable is a directory of source plus a Node runtime, or a bundle — the biggest operational difference when shipping.

Node has had a built-in runner since 18 (node --test with node:assert), which is the closest thing to go test; most projects still use vitest or jest for watch mode, mocking, snapshots and a browser environment. What has no counterpart at all is the doc example — Go compiles and runs the examples in your documentation, and nothing here does. There is no -race either, because there is no race, and no built-in benchmark harness or coverage tool: those are flags on whichever runner you chose.

Because the Go runtime ships with the module, size shapes every decision: a trivial program is around 2MB uncompressed, and TinyGo is the usual answer at a fraction of that, with meaningful standard-library gaps (reflection, parts of net, goroutine scheduling differences). wasm_exec.js is the glue and must come from the same Go version as the build — a mismatched pair fails at instantiation with unhelpful errors. Goroutines do work: the runtime multiplexes them onto the single browser thread, so they are concurrency without parallelism, exactly like promises.

Three practical rules. js.FuncOf registers a callback and must be Release()d or it leaks, and the program must not return from main while callbacks are live — which is why select {} appears in every example. Only primitives, strings and byte slices cross; a struct becomes a map[string]any you build by hand, or JSON on both sides, which is usually simpler. And each crossing is a real conversion, so the FFI rule applies: cross rarely with large payloads rather than often with small ones. GopherJS is the alternative — it compiles Go to readable JavaScript rather than WASM, with far better interop and a much smaller footprint, at the cost of goroutine fidelity.

The dominant pattern for a Go tool is to publish platform binaries and a small npm package that downloads the right one — which is how esbuild reaches millions of installs without a line of its logic being ported. WASM earns its place when the code must run in the page, or in an edge runtime with no processes: a parser, a codec, a crypto or image pipeline, anything CPU-bound with a coarse interface. And when the work is DOM manipulation, fetch orchestration or UI state, the honest answer is to write it in JavaScript — the boundary cost of doing it from Go exceeds what the port saves.