C.CodeCompared.To/JavaScript

console.log appends the newline, converts whatever you give it to text, and separates several arguments with spaces — so it is closer to puts than to printf. There is no exit status to return: a browser script simply finishes, and Node uses process.exit when a status matters.

This is the single largest working difference. A C build is a whole-program check: every call is against a declaration, every type is known, and a mistake stops the build. JavaScript checks syntax up front and nothing else, so the equivalent safety net has to come from tests, from linting, or from TypeScript — which is exactly why TypeScript exists.

The precision moved from the format string onto the value: %.2f became toFixed(2), which returns a string. Because there is no format string there is no way to pass the wrong number of arguments or the wrong conversion — the two most common printf mistakes cannot be written. What you lose is field widths, which come back as padStart and padEnd.

Notice that count and ratio both report number — there is no separate integer type to distinguish them. typeof answers with one of a short fixed list (number, string, boolean, bigint, symbol, undefined, function, object), and everything structured, including arrays and null, answers object.

This is what makes the language flexible and what makes large programs in it hard: nothing records what a name is supposed to hold, so the only way to know is to read every assignment to it. The discipline that replaces the compiler is convention — one type per variable, enforced by review, by a linter, or by moving to TypeScript, where these declarations come back.

If you want C’s meaning you need Object.freeze, and it is shallow — freezing an object does not freeze the objects inside it. In practice const is used almost everywhere in modern JavaScript simply because a name that never gets repointed is easier to read; the immutability you may be expecting from the keyword is not part of the deal.

Reading a field that does not exist gives undefined rather than failing, which is the behavior that turns a typo into a silent wrong answer instead of a compile error. The two absent values compare equal under == and unequal under ===, and typeof null famously answers "object" — a bug from 1995 that can no longer be fixed without breaking the web.

An engine typically stores a small integer unboxed and a large one as a heap double, and it will change representation underneath you when an array stops being uniform. That is why there is nothing meaningful to report for sizeof, and why the typed arrays in the last section of this page are the only place where a byte count is a real answer.

The two columns agree exactly about 0.1 + 0.2, because both are doing the same IEEE 754 arithmetic. Where they part company is 7 / 2: C picks integer division from the operand types and gives 3, while JavaScript has no integer type to pick, so it gives 3.5. Math.trunc, Math.floor and the | 0 idiom are how you get C’s answer back.

The last comparison is true, which is the whole problem: two different integers landed on the same double. This is why a JSON payload carrying a 64-bit database identifier must send it as a string — parsing it as a number silently corrupts it. The fix inside the language is BigInt, two rows down.

1 << 40 prints 256, not a trillion — the shift count is taken modulo 32, so it shifted by 8. >>> is the one operator C has no spelling for: it shifts in zeroes regardless of sign, which is how you read a 32-bit value as unsigned. For genuine 64-bit bit work, use BigInt, whose operators do not truncate.

One row where the two disagree is rounding a tie: C’s round goes away from zero, so round(-2.5) is −3, while Math.round always goes toward positive infinity and gives −2. The other thing to carry over: % works on non-integers here (7.5 % 2 is 1.5), because there are no integers for it to insist on.

The columns disagree on purpose: 21! overflows an unsigned 64-bit integer and the C column prints the wrapped value, while the BigInt grows to fit. The deliberate friction is that BigInt and Number will not add — mixing them throws rather than silently rounding, which is the mistake the type exists to prevent. Bitwise operators on BigInt do not truncate to 32 bits either, so this is also the way to do genuine 64-bit bit manipulation.

strlen walks to the terminator every time it is called, which is why the C loop above is accidentally quadratic; .length is a stored property. The other habit to unlearn: there is no buffer to size and no terminator to leave room for, so the entire family of off-by-one string bugs simply has nowhere to live.

The silent no-op is a genuine trap — in strict mode (which every module and class body is) it throws instead, which is better. Because strings never change, two variables holding the same string can share one representation with no aliasing hazard, and the engine is free to store a concatenation as a rope until somebody actually reads it.

The emoji is one character, two UTF-16 code units, and four UTF-8 bytes, and each column reports the number its own representation makes natural. Spreading with [...string] iterates by code point rather than code unit, which is the fix for slicing a string in half through an emoji; Intl.Segmenter goes further and iterates by what a reader would call a character.

The += loop is not the performance trap it looks like: every major engine stores the intermediate result as a rope and flattens it only when the string is actually read. It is still worth reaching for join, because it says what you mean and does not depend on that optimization. What has genuinely gone is sizeof buffer - strlen(buffer) - 1, which is the arithmetic behind a large share of C buffer overflows.

A split with a regular expression separator covers what strtok’s multi-character delimiter set was for, and split("") gives you an array of single characters. The cost is an allocation per piece, which is the price of not modifying the input — and given that the input is a string, and strings cannot be modified, there was never an alternative.

Under the hood an engine really does keep a contiguous backing store and grow it geometrically, so the cost model matches your instincts — as long as the array stays uniform. Store a string in an array of numbers and the engine may switch to a boxed representation, which costs an indirection per element from then on. That is the JavaScript equivalent of a struct falling out of a register.

The safety here is real — nothing is corrupted — but the diagnosis is worse than C’s: instead of a crash near the mistake you get NaN propagating through a calculation until it surfaces somewhere unrelated. at(-1) is the modern way to reach the last element, and assigning past the end really does make a sparse array, whose holes read as undefined and are skipped by forEach but not by a for loop.

Unlike the equivalents in some languages these are eager: each one walks the whole array and builds a new one, so a three-stage chain over a million elements does three passes and two allocations. That is usually fine and occasionally not, which is when you write the single loop back out by hand. Note also [...numbers] before sort — sort reorders in place and would otherwise modify the original.

The default line prints 1 10 100 20 9 — correct string order, useless numeric order — and it is one of the most reliably surprising defaults in the language. The comparator has the same contract as qsort’s: negative, zero, or positive. Subtraction is the usual shorthand and is safe here, but it overflows for very large values in the same way it would in C, so (a > b) - (a < b) is still the careful spelling.

Because the key can be computed, the same construct serves as your symbol table, your configuration, and your JSON. Engines optimize the struct-like use heavily — an object whose shape never changes gets a hidden class and field access compiles to an offset load, exactly like C — which is why adding fields to an object after creating it is the one habit that quietly costs performance.

The flexibility is real and so is the cost: a typo like config.retrys reads as undefined instead of failing to compile, and the assignment config.retrys = 5 creates a second field rather than correcting the first. This is the single most common source of silent bugs coming from C, and the reason large codebases either freeze their objects or move to TypeScript.

Map also keeps insertion order, accepts objects as keys (compared by identity, like a pointer), and has a real size rather than requiring Object.keys(...).length. Its sibling Set is the same idea without values. Use a plain object for a record with known fields and a Map for a lookup table whose keys arrive at run time.

The C column only manages the flat case, and it would need escaping logic the moment a name contained a quote. What JSON cannot carry is worth knowing before you rely on it: no functions, no undefined (the key is dropped), no cycles (it throws), and a Date comes back as a string. For a byte-exact wire format you are back to the typed arrays in the next section.

this is the hidden first argument, exactly as &shape is in the C column. The methods live on Rectangle.prototype, one copy shared by every instance, and a lookup that misses on the instance walks up that chain — so this is closer to a hand-rolled inheritance-by-delegation scheme than to a compiled vtable. The class keyword is syntax over that mechanism, not a new one.

The function knows its own name, and multiplier(3) manufactures a genuinely new function that did not exist when the program started. That is the piece with no C equivalent: a function pointer can only ever point at code the compiler emitted, so the closest C gets is a struct holding a pointer plus the data it needs — which is what the next row is about.

The captured variable is not copied — the closure holds the same binding, which is why total ends up at 10 and why makeCounter’s count survives after the function that declared it has returned. That last part is what a C local cannot do: the closure keeps the variable alive on the heap, and the collector frees it when the last function holding it goes away.

The default value is evaluated at call time, in the function’s own scope, so function push(item, list = []) gets a fresh array on every call rather than sharing one. The rest parameter is a real array — it knows its length and has every array method — which is the whole difference from va_arg, where the count and the types are things you promised rather than things the language knows.

Redeclaring a function replaces it rather than adding an overload, silently — which is a real hazard in a file long enough that you forget. Math.abs needs only one form because there is only one number type, so the abs/labs/fabs family collapses; the price is that the dispatch you would have got from the type system is now an if ladder you maintain.

The detached call returns NaN rather than failing: outside strict mode this falls back to the global object, this.value is undefined, and undefined + 1 is NaN — so the increment silently went somewhere else. Inside a module or a class body, which are always strict, this is undefined instead and the same call throws, which is much easier to diagnose. An arrow function is the fix that removed most of this pain: it has no this of its own and uses the one from where it was written, which is why callbacks are almost always arrows now. When you do need to pin a normal function to a receiver, bind returns a new function with it attached — the closest thing in the language to writing the pointer argument out by hand.

The three that surprise everyone: the string "0" is truthy (it is a non-empty string), and both [] and {} are truthy because every object is. So if (list) does not test whether a list has anything in it — that is if (list.length). The full falsy list is false, 0, -0, "", null, undefined and NaN, plus 0n. Note that the C column has the mirror-image trap in its last line: a char * pointing at the empty string is a non-null pointer, so if (empty) is true there and false here.

Read the last line twice: an empty array equals false under ==, while if ([]) takes the true branch. Both are consistent with the rules and neither is what anyone means. The working advice from every style guide is to use === everywhere, with the single exception of value == null, which is the idiomatic test for "null or undefined".

Because NaN is not equal to itself, indexOf can never find one — but includes can, since it uses a slightly different comparison. Use Number.isNaN rather than the older global isNaN, which converts its argument first and therefore claims that the string "abc" is NaN. A NaN spreading through a calculation is the usual symptom of the "out of range reads as undefined" behavior two sections up.

The last two lines are the reason ?? was added: || falls back on every falsy value, so a legitimate 0 or "" gets replaced by the default. ?? falls back only on the two absent values, which is almost always what a default is meant to mean. ?. also works before a call (callback?.()) and before a subscript (list?.[0]).

Reading a let before its declaration throws instead — the "temporal dead zone" — which is the behavior you want and the reason var is effectively deprecated. The practical rule for arriving from C: use const by default, let when the name must be reassigned, and never var.

The var line prints 3 3 3: one variable, shared by all three closures, holding the value that ended the loop. let in a for header is special-cased by the language to create a new binding per iteration, so it prints 0 1 2. Before let existed the workaround was to wrap the body in an immediately-invoked function, which is the same trick as copying the value into a struct in the C column.

A labeled continue exists too, and jumps to the next iteration of the labeled loop. What is missing is jumping forward to a cleanup label, which is C’s other main use of goto — that job belongs to try/finally, two sections down. There are no other jumps: you cannot label an arbitrary statement and go to it.

The three C failure modes — leak, double free, use-after-free — all disappear, and so does the ownership question that shapes every C interface: nothing needs to document who frees what. What replaces the leak is the retained reference: a value kept in a long-lived array, a closure, or an event listener nobody removed is still reachable and therefore still alive. That is the leak you will actually hunt.

The { ...object } spread is a shallow copy — one level deep, so a nested object is still shared, exactly like copying a C struct that contains a pointer. Function arguments follow the same rule: the reference is passed by value, so reassigning the parameter inside the function changes nothing outside, but mutating what it points at does.

structuredClone handles cycles, Map, Set, Date and typed arrays, which is more than the old JSON.parse(JSON.stringify(x)) trick ever did. What it will not clone is a function, a DOM node, or a class instance’s prototype — it throws on the first and returns a plain object for the last. The shallow line above is the bug it exists to prevent, and it is the same bug as copying a C struct full of pointers with memcpy.

The catch is that the language’s own conversions do not throw — Number("bad") gives NaN, parseInt("12abc") gives 12, and an out-of-range subscript gives undefined. So arriving from C you get exceptions where your code raises them and silent bad values everywhere else, which is why validating at the boundary matters more here than it does in a language that checks types for you.

Note the ordering the output proves: finally runs after the return value has been computed but before the function actually returns. That makes it the right place for closing a file or releasing a lock, and the wrong place for a return of its own — a return inside finally silently replaces the one that was on its way out, including replacing an in-flight exception.

A catch clause catches everything and then sorts it out with instanceof, since there are no typed catch clauses. Anything at all can be thrown — a string, a number — but do not: only an Error carries a stack, and losing the stack is the difference between a five-minute diagnosis and an afternoon.

Read the output order rather than the source order: everything synchronous finishes first, then all queued promise callbacks (microtasks), then the timer callbacks (macrotasks) — which is why a setTimeout(fn, 0) still runs after a promise that resolved much later in the source. There is no blocking sleep in the language at all, deliberately: on a page it would freeze the interface, and the queue is what replaces it.

The async wrapper around the whole example is only needed because await must be inside an async function in a script; inside a module it works at the top level. Promise.all is the important habit — two awaits in a row are sequential, which is usually a mistake when the two operations do not depend on each other. Nothing here is a second thread: it is one thread interleaving.

The timer was asked for zero milliseconds and fires only after the loop completes, because the queue is not consulted until the current work returns. The real answers are to break the work into chunks that yield between them, or to move it off the thread entirely — a Web Worker in the browser, a worker thread in Node — which communicates by copying messages rather than by sharing memory, so none of the data-race problems you know from C threads apply.

The generator is an infinite sequence and the loop simply stops taking values, which is safe because nothing is computed until it is asked for. The mechanism is the same one async/await is built on — a function whose frame survives being suspended — and it is the closest the language comes to the coroutine you would have to hand-roll as a state machine in C.

The buffer is zero-filled at creation, so it is calloc rather than malloc, and its size can never change. A typed array clamps to its element type on write — storing 300 in a Uint8Array gives 44, exactly as assigning to an unsigned char would — and it bounds-checks on both read and write, so the worst an out-of-range index can do is read undefined.

Both columns print the bytes in the machine’s own order — 4 3 2 1 on anything little-endian — because both are looking straight at memory. That is the trap this makes easy to fall into: a typed array is fast precisely because it uses the platform order, so it is the wrong tool for a file or network format. The next row is the right one.

The two columns print the same four wire bytes, because both are writing big-endian deliberately. DataView also reads and writes at any byte offset, aligned or not, which a typed array cannot do — new Uint32Array(buffer, 1) throws. For parsing a binary format, DataView is the tool; typed arrays are for bulk data you produced yourself.

TextEncoder only ever produces UTF-8 — there is no option — while TextDecoder can be told to read other encodings. The gap the output shows is the whole hazard: four characters, five bytes. Any protocol whose length field counts bytes must be given the encoded length, not string.length, and that mistake is the JavaScript version of confusing strlen with a character count.

The two columns produce the same six bytes, and the C column also prints sizeof(struct Record) — 8, not 6, because the compiler padded length to a four-byte boundary. That gap is exactly why writing a struct straight to a file is not a format. JavaScript has no way to make that mistake, since there is no struct to write.

Imports are hoisted and resolved before any code runs, so the order of the statements does not matter and a circular import resolves rather than looping forever. Node also still supports the older require form, which is a function call and therefore can be conditional — the two systems interoperate awkwardly, and which one a file uses is decided by its extension and its package settings.

Both columns print 42, and the second one is running the same computation the first one compiles to. What crosses the boundary is only numbers: to pass a string or a struct you write it into the module’s linear memory — which is an ArrayBuffer, viewable with exactly the typed arrays from the previous section — and pass the offset. That is the whole interop model, and it is why those rows come first.