DEV Community: Arpan Singh

TypeScript 7 Just Shipped: I Checked Five Claims Going Around Against Microsoft's Own Numbers

Arpan Singh — Tue, 25 Aug 2026 07:12:18 +0000

TypeScript 7 went generally available on July 8, 2026. Within a day, the talking points had already calcified: 10x faster, half the memory, same compiler under the hood, just bump the version and go.

Some of that is true. Some of it is rounding a real number into a rounder, less accurate one. And one detail — the one that will actually cost teams engineering hours — barely made it into the first wave of coverage at all.

So instead of another "here's what's new" recap, here are the five claims already circulating, checked one at a time against Microsoft's own release post and the surrounding reporting. Verdicts below, in order of how much they matter to your Monday morning.

At a glance

#	The claim	Verdict
1	"It's roughly 10x faster"	True — if anything, undersells it
2	"It uses about half the memory"	Overstated — real number is 6–26%
3	"Same compiler, just written in Go"	True in behavior, not in effort
4	"Just bump the version and move on"	Depends entirely on your stack
5	"Still experimental, not proven at scale"	False

Claim 1 · "It's roughly 10x faster"

Verdict: True — and in the best case, it undersells it.

Microsoft's own release post gives a real table, not a marketing bullet. Running TypeScript 6 against TypeScript 7 on five real open-source codebases, at the default setting of 4 parallel type-checker workers:

Codebase	TypeScript 6	TypeScript 7	Speedup
VS Code	125.7s	10.6s	11.9x
Sentry	139.8s	15.7s	8.9x
Bluesky	24.3s	2.8s	8.7x
Playwright	12.8s	1.47s	8.7x
tldraw	11.2s	1.46s	7.7x

That's the conservative setting. TypeScript 7 ships a new --checkers flag that controls how many parallel type-checking workers run at once. Push it from the default of 4 to 8 on the same machine, and the VS Code build drops further — to 7.51 seconds, a 16.7x speedup over TypeScript 6.

The editor experience improved by a similar margin, and this is the number that will actually change how a build feels day to day. Opening a file with an error in the VS Code codebase used to take about 17.5 seconds before the first red squiggle appeared. In TypeScript 7, that's under 1.3 seconds — over 13x faster.

So "10x" isn't a rounded-up marketing number here. If anything, it's the floor.

Claim 2 · "It uses about half the memory"

Verdict: Overstated. The real number is a lot more modest — and still worth having.

This is the claim worth slowing down on, because it's a good example of how a real figure gets inflated as it travels between blog posts.

Microsoft's own GA-day benchmark table, on the same five codebases, shows full-build memory usage dropping between 6% and 26% — not 50%.

Codebase	TypeScript 6	TypeScript 7	Memory delta
VS Code	5.2GB	4.2GB	−18%
Sentry	4.9GB	4.6GB	−6%
Bluesky	1.8GB	1.3GB	−26%
Playwright	1.0GB	0.9GB	−11%
tldraw	0.6GB	0.5GB	−15%

None of that is a knock on the release. An 18% memory cut on a full VS Code build, stacked on the 11.9x speedup from Claim 1, is a genuinely good trade for a CI runner with fixed RAM.

But "half the memory" and "18% less memory" are different claims, and only one of them is what Microsoft's own numbers show for a full build. The more dramatic memory story appears to live in steady-state editor sessions rather than full builds — and that distinction got flattened somewhere between the preview-era blog posts and the recaps that followed.

Claim 3 · "It's basically the same compiler, just written in Go now"

Verdict: True about behavior. Not even close to true about what it took to get there.

Start with what Microsoft actually promises: TypeScript 7 is a port, not a rewrite. The team moved the existing structure, algorithms, and logic from the old JavaScript-based compiler (retroactively named Strada) into Go, file by file, rather than redesigning the type-checker from scratch. The stated goal was that code compiling cleanly under TypeScript 6 should compile identically under TypeScript 7.

That faithfulness is exactly why the choice of Go over Rust is worth understanding, rather than shrugging off as a language preference. TypeScript's lead architect, Anders Hejlsberg, has said the team evaluated Rust, C++, and Microsoft's own C# first.

Rust was ruled out for a structural reason, not a taste one. The compiler's internal representation — its abstract syntax trees and symbol tables — is full of cyclic references. Rust's ownership model makes that kind of cyclic structure genuinely painful to express without a garbage collector, which would have forced a redesign of the type-checker's core data model before any porting could start.

Go's garbage-collected, shared-memory model maps directly onto the existing shape: cyclic references just work, and goroutines give cheap parallelism across a single symbol table without redesigning anything.

C# lost out for a different reason. The existing codebase leans heavily functional with minimal use of classes, and Hejlsberg has said C#'s more object-oriented model was a worse structural fit than Go's function-and-struct approach.

The choice was not universally popular. It spilled across Hacker News, Reddit, and a long GitHub discussion thread, much of it from C# developers asking why Hejlsberg passed over his own language. His answer has been consistent throughout: Go was the lowest-level option that offered native-code performance, fine control over memory layout, cyclic data structures, and mature garbage collection, all at once.

There's a quieter cost buried in all of this that outlasts the language debate. For essentially its entire existence — roughly 14 years — the TypeScript compiler was self-hosted: written in TypeScript, compiling itself. That's over now. The compiler that checks your types is written in a language your types aren't written in, and contributing to it now requires knowing Go, not TypeScript.

For almost everyone who just uses TypeScript, this changes nothing about your day. For the smaller group who used to read the compiler's own source as a way of learning advanced TypeScript, that specific on-ramp just closed. It's a real if narrow loss — and it's the kind of detail a release note built around benchmark charts has no reason to mention.

Claim 4 · "You can just bump the version number and move on"

Verdict: For some teams, yes. For others, this is the claim that will eat your week.

This is the one first-look coverage most underserved, because it's not really about speed at all.

Before TypeScript 7, tsc was a JavaScript library living in your Node process. Tools called straight into it: ts-jest called ts.transpileModule(), typescript-eslint called ts.createProgram() to build a full language service, ts-morph walked the type graph through ts.createCompilerHost(), and ts-node hooked Node's module loader and delegated directly to the compiler.

TypeScript 7's compiler is a separate Go binary — the payoff of the port described in Claim 3. It doesn't live in your Node process anymore.

Anything built on "import typescript and call a function" is now talking to something that no longer exists in that form, and the failures rarely announce themselves as a TypeScript problem. A broken ts-node setup, for instance, tends to surface as an ESM configuration error — which sends people debugging the wrong layer for a while.

Three groups of tools are affected differently, and it's worth knowing which one you're in:

Custom AST transformer plugins (ts-patch, ttypescript, typia, and similar) have no JavaScript plugin surface left to call into. There's no clean patch; the real fix is moving transforms to something like SWC or Oxc and letting the Go compiler handle type-checking only.
Tools that hook the module loader — ts-node being the clearest case — delegate to a JavaScript tsc that no longer exists in the expected form.
Tools built on the programmatic Compiler API (typescript-eslint, ts-morph) are fine for now, but only because Microsoft explicitly deferred this problem. TypeScript 7.0 ships with no stable API at all. That's coming in 7.1, still some months out.

To bridge that last gap, Microsoft published a compatibility package, @typescript/typescript6, which installs a tsc6 executable and re-exports the old TypeScript 6.0 API. The intended pattern is an npm alias: point typescript at the 6.0 compatibility package for tools that still need the old API, and add a separate alias so tsc resolves to TypeScript 7 for your own build and CI steps.

Tools that never depended on the Compiler API in the first place — Biome and esbuild among them — are simply unaffected, since they ship their own parsers.

If you're on Vue, MDX, Astro, Svelte, or Angular's Volar-based tooling, you're stuck on TypeScript 6.0 for editor support specifically, since those tools embed TypeScript's own API into their language services and that API doesn't exist yet in 7.0. Microsoft's release notes say this plainly rather than glossing over it.

There's also a tsconfig layer to this claim. TypeScript 7 hard-adopts TypeScript 6.0's newer defaults and turns a decade of soft deprecations into flat errors:

Change	Detail
strict	Now true by default
module	Defaults to esnext
target: es5	No longer supported
moduleResolution: node / classic	No longer supported
module: amd, umd, systemjs, none	Removed
baseUrl	Gone — migrate to paths relative to project root
rootDir	Now defaults to ./ instead of being inferred
types	Defaults to an empty array instead of all @types
downlevelIteration, esModuleInterop: false, alwaysStrict: false	Rejected outright

Two language-level changes rode along with the tooling shift, and they're worth knowing about even if they're narrow. Template literal type inference now treats a multi-byte character like an emoji as one unit instead of splitting it into a UTF-16 surrogate pair, which breaks any type-level string utility that leaned on the old behavior. And TypeScript's JSDoc-based JavaScript support was reworked to match .ts semantics more closely, changing how older patterns like @enum and Closure-style function types get interpreted.

So: if your stack is tsc and nothing else, this claim is basically true. If it includes any of the tools above, it's the opposite of true — and the failure mode looks like a config bug rather than a version bump.

Claim 5 · "This is still experimental, not proven at real scale"

Verdict: False. This has already been run hard, by people with a lot to lose.

Beyond Microsoft's own large internal codebases (Loop, Office, PowerBI, Teams, Xbox), the company says it spent the past year working with Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel, and VoidZero — the team behind Vite, Rolldown, and Oxc — on pre-release builds of TypeScript 7.

Some of the reported numbers are specific enough to be more than a testimonial slide:

Company	Reported result
Slack	40% less merge queue time; CI type-checking down from ~7.5 min to ~1.25 min
Vanta	Up to a 9x speedup on one of their largest projects
Microsoft (internal team)	~400 engineering hours/month previously lost to CI waits, recovered
Canva	Time to first error in-editor: ~58s → ~4.8s

Slack's editor had reportedly gotten slow enough that engineers were leaning on CI for full type-checks instead of trusting the local language server.

Microsoft also reports that the new language server cut failing language-server commands by more than 80% and crashes by more than 60%, compared to TypeScript 6's. That's a meaningful reliability claim stacked on top of the speed one.

Worth flagging plainly: every number in this section is Microsoft measuring Microsoft's software, plus companies Microsoft chose to name. It is not an independently replicated audit, and it would be a mistake to read it as one. But "not proven at scale" doesn't hold up either — this is a different category of evidence than a beta announcement with a demo gif.

So — should you upgrade this week?

If your usage is limited to running tsc for type-checking and builds — upgrade now. That's the scenario Microsoft optimized for first, and it carries the least ecosystem risk of anything on this list.
If your pipeline includes typescript-eslint, ts-morph, ts-node, ts-patch, ttypescript, or a custom transformer — don't do a blind upgrade. Use the npm alias pattern: TypeScript 7 for your own tsc invocations, the 6.0 compatibility package for anything still calling the old API, until either the tool updates or TypeScript 7.1 ships its stable API.
If you're on Vue, Astro, Svelte, MDX, or Angular — stay on TypeScript 6.0 for editor tooling for now. You can still get the CLI type-check speed from TypeScript 7 without touching your editor's language server plugin.

Either way: don't take my word, Microsoft's word, or anyone else's for the speedup on your specific codebase. npx tsc --version tells you what you're running, and installing TypeScript 7 alongside your current setup via an alias costs nothing to try before you commit.

Sources

Microsoft — Announcing TypeScript 7.0 (July 8, 2026)
Microsoft — Announcing TypeScript 7.0 RC (June 18, 2026)
Microsoft — Progress on TypeScript 7 – December 2025
microsoft/typescript-go — Why Go? (GitHub Discussion #411)
The New Stack — Microsoft TypeScript Devs Explain Why They Chose Go Over Rust, C#
DevClass — TypeScript inventor Anders Hejlsberg: AI is "a big regurgitator of stuff someone has done"
BeyondIT — Three Tools in Your TypeScript Stack Will Break on the 7.0 Upgrade
webhani — Preparing for TypeScript 7.0: Breaking Changes and Migration Steps
Visual Studio Magazine — TypeScript 7.0 RC Moves Microsoft's Go Rewrite Into the Mainline Compiler
Neowin — Microsoft releases TypeScript 7.0, and it's 10x faster than the previous version

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Big-O Notation Explained: The Regex That Took Down Cloudflare for 27 Minutes

Arpan Singh — Fri, 24 Jul 2026 12:09:43 +0000

At 13:42 UTC on July 2, 2019, Cloudflare's network stopped answering requests. Not slow. Down.

For 27 minutes, a huge slice of the web returned 502 errors instead of loading.

The cause wasn't a DDoS attack or a hardware failure. It was one regular expression, in one firewall rule, pushed to every server Cloudflare owns at the same time.

That regex had a property called catastrophic backtracking. Feed it the wrong kind of input, and instead of matching in microseconds, the matching time roughly doubles with every extra character.

Cloudflare's own post-mortem lays it out plainly: a WAF rule update shipped a regex that ate CPU on every core handling HTTP and HTTPS traffic, worldwide, within minutes of going live.

That single deployment is the entire reason Big-O notation is worth learning as a working developer, not just memorizing for an interview and forgetting.

Every data structure and algorithm in this series has a Big-O. Get it wrong, and code that sails through testing can take your production system down exactly like it did for Cloudflare.

What Big-O Actually Measures

Big-O is not a stopwatch. It doesn't tell you an operation takes "3 milliseconds."

It tells you how the cost of an operation grows as the input grows. That's the whole idea.

Say a function checks every item in a list once. Double the list, and the function does roughly double the work. That growth pattern, cost scaling linearly with size, is what O(n) describes.

Big-O deliberately throws away two things: the exact hardware you're running on, and small, constant-size costs. It keeps only the part that matters once your input gets big: the shape of the growth curve.

That's also why the Cloudflare regex was so dangerous. Its growth curve wasn't linear, or even quadratic. It was exponential, and exponential curves look almost flat for small inputs, then explode the moment the input crosses a threshold. That's exactly the kind of bug that passes every test and detonates in production.

Dropping Constants: Reading Big-O Like an Algebra Problem

Say you profile a function and its operation count comes out to:

3n² + 5n + 2

Big-O notation calls this function O(n²). Here's why, term by term.

Drop the lower-order terms. Once n gets large, 5n and 2 stop mattering next to 3n². At n = 1,000,000: 3n² is 3 trillion, 5n is 5 million. A rounding error by comparison.

Drop the constant multiplier. Whether it's 3n² or 30n², both describe the same shape of growth: quadratic. The multiplier affects real-world speed, which is a separate conversation from Big-O, but it doesn't change the growth curve.

So 3n² + 5n + 2 becomes O(n²), every time. This is the most common thing beginners get wrong — they see two nested loops and one extra pass, and try to write O(2n² + n). Nobody writes that. It's O(n²).

The Complexity Ladder

Here's every complexity class you'll run into in this series, best to worst, each with one operation you already use.

	Notation	Name	A real example
🟢	O(1)	Constant	Reading arr[5] from an array
🟢	O(log n)	Logarithmic	Binary search on a sorted array
🟢	O(n)	Linear	Scanning a list once for a value
🟡	O(n log n)	Log-linear	Sorting with merge sort or Python's Timsort
🟠	O(n²)	Quadratic	Comparing every pair with nested loops
🔴	O(2ⁿ)	Exponential	Naive recursive Fibonacci — and Cloudflare's regex
🔴	O(n!)	Factorial	Trying every ordering of n items

Green means it scales to millions of items without blinking. Yellow still holds up at real-world scale. Orange starts hurting once n hits the thousands. Red is the zone Cloudflare's regex lived in — fine for tiny inputs, catastrophic past a threshold.

Each step down that table is a different universe of slowdown. At n = 20, O(n) and O(2ⁿ) are both fast. At n = 40, O(n) is still instant. O(2ⁿ) has over a trillion steps left to run.

Best Case, Average Case, Worst Case

Big-O by itself usually means the worst case: the input that makes an algorithm work hardest.

Linear search through an unsorted list is O(n) worst case (the value isn't there, or it's last) but O(1) best case (it's the first element checked).

Quicksort is the classic split-personality algorithm: O(n log n) on average, but O(n²) worst case if it keeps picking a bad pivot on already-sorted data. That's exactly why production sort implementations (Python's Timsort, V8's sort) don't run plain quicksort. They hedge against that worst case directly.

When someone asks "what's the Big-O of this," they almost always mean the worst case unless they say otherwise. That's the convention this series follows too.

Space Complexity: The Other Half of the Bill

Big-O also measures memory, not just time. Same rules, different resource.

An algorithm that builds a second array the same size as the input is O(n) space. One that tracks a couple of variables, regardless of input size, is O(1) space.

Recursive functions carry a space cost most beginners miss: every call sits on the call stack until it returns. A recursive function that goes n levels deep uses O(n) space on the stack alone, even without allocating a single array. That'll matter once recursion shows up properly in Day 3.

Amortized Time: Why "Append" Isn't Always O(1)

Both Python's list.append() and JavaScript's array.push() get described as O(1). That's not the whole story.

Under the hood, both languages back their dynamic arrays with a fixed-size block of memory. Fill it up, and the next append has to allocate a bigger block and copy every existing element over — an O(n) operation.

Both languages soften this the same way: they over-allocate, growing the backing array by a multiplying factor instead of one slot at a time. Resizes get rarer as the array grows, so the average cost per append, across many appends, still comes out to O(1). That average has a name: amortized O(1). It's worth knowing before dynamic arrays show up properly in Day 2.

How to Read Your Own Code's Complexity

There's a repeatable process here, simpler than it looks once you've done it a few times.

flowchart TD
    A[Look at the loops] --> B{Loops nested?}
    B -->|No, sequential| C["Add them: O(a) + O(b), keep the larger term"]
    B -->|Yes| D["Multiply them: O(a) times O(b)"]
    D --> E{Does each step cut<br/>the input in half?}
    E -->|Yes| F["O(log n) for that part"]
    E -->|No| G["O(n) for that part"]
    C --> H{Any recursive calls?}
    G --> H
    F --> H
    H -->|Yes| I["Count total calls made,<br/>not just the visible loop"]
    H -->|No| J["Done, that's your Big-O"]

Walk that against a real function:

def has_duplicate_pair(nums):
    for i in range(len(nums)):             # loop 1: n iterations
        for j in range(i + 1, len(nums)):  # loop 2: nested inside loop 1
            if nums[i] == nums[j]:
                return True
    return False

Two loops, nested. That means multiply. Loop 1 runs n times, loop 2 runs roughly n times too (shrinking a bit each pass, a detail Big-O ignores). O(n) times O(n) = O(n²).

Compare that to a function that looks similar but isn't:

def has_negative_or_over_limit(nums, limit):
    for n in nums:               # loop 1: n iterations
        if n < 0:
            return True
    for n in nums:                # loop 2: separate, not nested
        if n > limit:
            return True
    return False

Two loops again, but sequential, not nested. Add instead of multiply: O(n) + O(n), the constant drops, and it's O(n). Seeing "two loops" and assuming O(n²) automatically is one of the most common mistakes in code review.

The Benchmarks: What This Looks Like on Real Hardware

Theory is one thing. Here's what these growth curves look like measured for real — Python 3.12 and Node.js 22, same machine, same inputs, timed with timeit and process.hrtime.bigint().

O(1): array index access

n	Python (ns/op)	Node.js (ns/op)
1,000	43.3	14.2
10,000	31.3	9.5
100,000	32.1	10.4
1,000,000	30.8	27.2

Flat, as expected. The time doesn't track n at all. The small jump at 1,000,000 in the Node.js column isn't a Big-O violation; that's the array outgrowing CPU cache, a real hardware effect Big-O doesn't model. Big-O describes algorithmic growth, not what the cache hierarchy underneath it is doing.

O(log n): binary search

n	Python bisect (ns/op)	Node.js (ns/op)
1,000	114.8	35.8
10,000	121.7	24.9
100,000	156.8	25.4
1,000,000	159.0	28.6

The input grew 1,000x. The time barely moved. That's the entire pitch for logarithmic algorithms in one table.

O(n): linear search, worst case (target never present)

n	Python (µs/op)	Node.js (µs/op)
1,000	6.62	1.11
10,000	59.49	10.14
100,000	616.47	102.58
1,000,000	6,060.19	1,514.06

10x the input, roughly 10x the time, in both languages. Textbook linear.

O(n log n): sorting (Python's Timsort, V8's sort)

n	Python (ms/op)	Node.js (ms/op)
1,000	0.083	0.202
10,000	1.262	2.057
100,000	18.386	26.654
1,000,000	260.294	326.918

Growing faster than linear, much slower than quadratic — the middle ground n log n describes. Don't read too much into Python edging out Node.js here; it's one machine, one run, and the gap is small enough that engine warm-up explains most of it, not "Python's sort is better."

O(n²): checking every pair for duplicates, nested loops

n	Python (ms/op)	Node.js (ms/op)
500	3.25	0.09
1,000	13.82	0.34
2,000	53.97	1.32
4,000	219.10	5.29

Double n, and the time roughly quadruples, in both languages, at every step. That's the signature of O(n²): a pattern you can watch happen in real numbers.

O(2ⁿ) vs O(n): naive vs. memoized Fibonacci

n	Naive Python (ms)	Memoized Python (µs)	Naive Node.js (ms)	Memoized Node.js (µs)
20	0.663	7.63	0.091	3.61
25	8.613	6.01	0.706	4.31
30	78.953	6.84	7.700	5.18
32	206.629	7.15	20.428	5.11

This is the table that matters most in the whole post. Going from n=30 to n=32 — adding two — makes the naive version take roughly 2.6x longer, in both languages independently. That 2.6x isn't a coincidence: it's the golden ratio squared, baked into how Fibonacci's recursion tree branches.

The memoized version barely moves across the entire range. One dictionary, or one Map, turns an O(2ⁿ) function into an O(n) function. The benchmark shows exactly what that's worth: milliseconds versus microseconds.

The benchmark scripts used to generate the numbers listed above have been uploaded to GitHub for reference.

def fib_naive(n):
    if n <= 1:
        return n
    return fib_naive(n - 1) + fib_naive(n - 2)

def fib_memo(n, cache={}):
    if n <= 1:
        return n
    if n in cache:
        return cache[n]
    cache[n] = fib_memo(n - 1, cache) + fib_memo(n - 2, cache)
    return cache[n]

Where the Regex Went Wrong

Back to Cloudflare, with the vocabulary to actually explain it now.

A backtracking regex engine, faced with an ambiguous pattern, can end up trying every possible way to match it — the regex equivalent of the naive Fibonacci function above, except n is the length of the input string, and there's no memoization built in by default.

Small inputs, like most real traffic, never trigger the worst case. That's exactly why the rule passed testing.

One request with the right shape of pathological input turned a normally instant regex into an O(2ⁿ) computation, run on every CPU core, on every server, at the same time. That's the outage in one sentence.

What's Next

Day 2 starts with arrays. There's enough ground there to split it: fundamentals and core operations first, then patterns like two-pointer and sliding window as their own follow-up. Linked lists get the same treatment once we reach them: singly and doubly linked first, then the interview-heavy patterns (reversal, cycle detection, merging) as a separate post.

Every post from here on states the time and space complexity of every operation it covers. This is the post that vocabulary comes from.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!

Arrays Explained from Memory to Big O (With Real Benchmarks)

Arpan Singh — Fri, 24 Jul 2026 12:08:55 +0000

This Loop Should Delete Three Items. It Deletes Two.

scores = [45, 30, 88, 92, 15, 67]

for score in scores:
    if score < 50:
        scores.remove(score)

print(scores)

Read that and guess the output. Three values are under 50: 45, 30, 15. So the obvious guess is [88, 92, 67].

Run it, and Python prints [30, 88, 92, 67].

30 survives. Nothing crashed, no exception, no warning. The code just quietly kept a value it was explicitly told to remove.

Swap the language and the bug follows you:

const scores = [45, 30, 88, 92, 15, 67];

for (let i = 0; i < scores.length; i++) {
  if (scores[i] < 50) {
    scores.splice(i, 1);
  }
}

console.log(scores);

Same input, same wrong survivor: [ 30, 88, 92, 67 ].

Two different languages, two different removal methods, the exact same failure. That's not a coincidence. It's what an array is underneath both of them, and Day 2 starts there.

What An Array Actually Is

Forget the syntax for a second. At the hardware level, an array is a promise: a single, unbroken block of memory, where every element sits the same distance apart.

That promise is what makes scores[3] fast. The computer doesn't search for index 3. It calculates an address directly: start of the block, plus 3 times the size of one element, done. One arithmetic operation, one memory read. That's the entire reason array access is O(1): it's not clever, it's just math.

Deletion breaks that promise, at least temporarily. Remove the item at index 0, and there's now a gap at the front of an otherwise unbroken block. The only way to restore the promise (a single contiguous run with no holes) is to physically slide every element after the gap back by one position.

That slide is the whole story. It's an O(n) memory move hiding behind a one-line method call, and it's exactly what desynced the loop above.

Why The Loop Skips

Walk scores.remove(score) through what actually happens in memory, one step at a time:

The loop's cursor sits at index 0. It reads 45, sees it's under 50, and removes it.
Removing index 0 slides everything left by one slot. The value that used to be at index 1, 30, is now sitting at index 0.
The loop cursor doesn't know that happened. It advances to index 1, as it always does.
Index 1 now holds 88, the value that used to be two slots over. 30 was never re-examined. It's still in the array when the loop ends, because the loop moved past the exact slot it landed in.

The fix follows directly from the same mental model. Either walk the array backward, so every shift happens behind the cursor instead of into it:

scores = [45, 30, 88, 92, 15, 67]

for i in range(len(scores) - 1, -1, -1):
    if scores[i] < 50:
        scores.pop(i)

or don't mutate the array you're iterating at all, build a new one instead:

scores = [45, 30, 88, 92, 15, 67]
scores = [s for s in scores if s >= 50]

The second version is also the one worth defaulting to. It sidesteps the shifting problem entirely instead of just working around it.

Static Arrays vs. What You're Actually Using

C's int arr[10] is a static array: one fixed-size block, allocated once, that can never grow. Ask for an 11th slot and there's no polite failure. You're writing into memory that belongs to something else.

Python's list and JavaScript's Array aren't that. They're dynamic arrays: a static array under the hood, wrapped in logic that swaps in a bigger block once the old one fills up. Every .append() or .push() you've ever called was secretly asking "is there room?" before it ever touched memory.

That wrapping is why beginners get told arrays are O(1) to append to, and it's mostly true, but "mostly" is doing real work in that sentence, covered next.

Every Core Operation, Rated

	Operation	Complexity	Why
🟢	Access by index	O(1)	Direct address math, no searching
🟢	Append / pop at the end	O(1)*	No shift needed; *occasionally O(n) — grows past capacity, shrinks past half capacity, more below
🟠	Search (unsorted)	O(n)	No shortcuts — check every slot until found
🔴	Insert / delete at the start	O(n)	Every remaining element shifts by one
🔴	Insert / delete in the middle	O(n)	Same shift, just for a shorter stretch

The pattern in that table is the entire lesson: where in the array you operate matters as much as what operation you run. The end is cheap. The front is expensive. That's not a Python or JavaScript quirk. It's physics, the same physics that broke the loop above.

The Asterisk on "O(1) Append"

Dynamic arrays grow by over-allocating: when the backing block fills up, they don't grab one more slot, they grab a noticeably bigger block and copy everything over. That copy is O(n), but it happens rarely enough that the average cost per append, over many appends, still comes out to O(1). That average has a name: amortized O(1).

"Rarely enough" isn't hand-waving. CPython's growth pattern is public, and it's checkable from Python itself, since sys.getsizeof() reports the backing array's real allocated size, not just the list's length. Appending one item at a time and watching that number jump gives you the exact resize points, live, on CPython 3.12:

List length at resize	Backing array size (bytes)	Slots allocated
1	88	4
5	120	8
9	184	16
17	248	24
25	312	32
33	376	40

Between each row, appends are just writing into already-reserved space: genuinely O(1), no copying at all. The resize itself, on that one unlucky append, is O(n). Spread that occasional O(n) cost across all the free appends in between, and it averages out to O(1) per call.

Shrinking runs the same machinery in reverse, on a different trigger than most people guess. pop() doesn't hand memory back the moment the list gets smaller: CPython only reallocates down once the length falls under half of what's currently allocated, not the instant a single slot goes unused. Pop a 33-item list down to empty and the real shrink points, traced the same way with sys.getsizeof(), land at lengths 16, 11, 7, 5, 1, and 0. Compare that to the growth table above and the thresholds don't mirror each other; growing and shrinking are governed by two separate rules sharing one function, not a single reversible curve.

V8 runs the same strategy for JavaScript arrays, over-allocating on growth instead of resizing one slot at a time. That's why .push() gets the same amortized O(1) label .append() does.

One More Thing V8 Tracks That CPython Doesn't

V8 keeps something called an array's elements kind — a running classification of what's actually in it: all small integers, mixed with floats, holding arbitrary objects, or containing gaps. V8's own engineering blog lays out the mechanism: arrays built with actual gaps in them (skipped indices, or presized with new Array(n) and filled out of order) get marked holey, and every read from a holey array carries an extra check a gap-free ("packed") array skips.

That transition only runs one direction: specific to general, packed to holey. It's permanent. Fill every gap in a holey array later, and V8 still won't reclassify it back to packed. The practical takeaway: build arrays in order, front to back, if you want V8 to keep every optimization available to it.

How much that actually costs in practice is genuinely inconsistent. A plain summation loop over a packed vs. a holey million-element array, benchmarked repeatedly on this machine, came back centered close to even, drifting up to roughly 13% either direction depending on the run, with no consistent winner. Real, but not the dramatic one-directional gap sometimes claimed for it online. The scripts to run that comparison yourself are in the attached zip.

The Benchmarks

Same rule as Day 1: no number below is estimated. Python 3.12 and Node.js 22, timed with time.perf_counter() and process.hrtime.bigint(), each operation paired with its opposite (append then pop, insert then remove) so the array's size stays constant across the whole run.

End of the array: append / pop

n	Python append (ns)	Python pop (ns)	Node push+pop (ns, combined)
1,000	44.9	31.0	10.0
10,000	31.4	31.0	1.9
100,000	32.1	30.9	2.0
1,000,000	31.7	34.6	1.7

Flat across four orders of magnitude, in both languages. That's the empirical signature of O(1). The Node numbers look almost too fast to be real; that's V8's JIT compiling this exact push-then-pop pattern more aggressively the longer the process runs, not a language-superiority result. Treat the flatness as the finding, not the specific nanosecond count.

Start of the array: insert / delete

n	Python insert(0) (µs)	Python pop(0) (µs)	Node unshift (µs)	Node shift (µs)
1,000	0.26	0.12	0.14	0.12
10,000	2.60	1.84	1.85	0.13
100,000	24.77	17.97	18.65	18.39
1,000,000	364.64	342.58	362.43	348.51

10x the input keeps landing close to 10x the time, in every column. That's the same linear signature the O(n) search benchmark showed on Day 1, now showing up for a different operation entirely. (Node's shift at n=10,000 reads oddly low next to its neighbors — at that size the fixed cost of the function call itself is still competing with the shift cost, so the line hasn't straightened out yet. It does by 100,000.)

Both scripts behind every number in this post (the Python and Node versions, plus the resize-point tracer and the packed/holey comparison) are packaged in arrays-ops-benchmark.zip, attached to this post.

Back to the Bug

The loop at the top of this post wasn't a trick question. It's the single most common way arrays bite working developers, in any language that has them, and it only looks mysterious until you've internalized what deletion actually costs.

Once you know an array is a contiguous block, and that removing from the middle means physically sliding everything after it, the loop's behavior stops being surprising. It's not broken. It's doing exactly what shifting a block of memory always does. The bug was ever expecting the cursor to notice.

Try it yourself before the next post: take the backward-iteration fix above, and instead of removing values under 50, remove every duplicate value from a list, keeping just the first occurrence of each. Same shifting mechanics, one extra piece of state to track. It's a good gut-check for whether the mental model actually stuck.

Originally published on ZyVOP

💡 For more articles like this, subscribe to the ZyVOP newsletter!