Why eager won

Two questions, and separating them is the point.

Why it did not fail like TF1: five differences, which compound. None of them is “static versus dynamic”.

1. Tracing runs your real Python. JAX’s jit traces the function by executing it with abstract values, so you write ordinary Python and get a graph as a result. TF1 made you write graph construction code — a different language wearing Python’s syntax. In JAX, if on a traced value fails with a clear error telling you to use lax.cond; in TF1, if silently baked in the build-time branch.
2. It is opt-in and removable. Delete @jit and the function still runs, eagerly, as normal NumPy-ish code. You debug in eager, then re-add the decorator. TF1 had no such mode — there was no “just run it” to fall back to.
3. Functional purity is enforced, not requested. JAX requires explicit PRNG keys and forbids in-place mutation of traced values, so the tracing model has no hidden state to get wrong. TF1’s variables, collections and control dependencies were a large mutable global namespace whose semantics were genuinely hard to hold in your head.
4. vmap and grad compose. JAX gave something eager mode could not: automatic vectorisation and arbitrary-order differentiation as composable transforms. That is a capability, not just a speed-up — a reason to accept the constraint rather than a tax on ignoring it.
5. It arrived after the war, into a niche. JAX targeted researchers who already accepted compilation for TPUs, at a point when nobody expected it to be the default framework.

Why it still did not win: because by 2018 the question had stopped being about design. PyTorch already had the pretrained weights, the tutorials, the answered questions, and the papers whose code you wanted to run. A framework’s value is mostly the work already written in it, and that is a quantity you cannot out-design. JAX also asked for a genuine concession — functional purity, no in-place mutation, explicit PRNG keys — which is a fine trade for a team that wants vmap and pjit, and a poor one for someone porting a repo.

So the two answers together give the lesson. The constraint was never the problem — making it mandatory, invisible and inescapable was, which is what TF1 did and JAX did not. And being right is not sufficient once network effects have settled, which is why JAX sits at a few percent while having demonstrably won the technical argument. torch.compile (Module 4) is what you build when you have absorbed both halves: the good idea, delivered as an opt-in decorator with a silent fallback, inside the ecosystem people are already in.

Because Python’s if runs when the graph is built, and the graph must encode a decision made when it is run. Those are different times, and TF1 gave you no syntax that spanned them.

# Silently wrong: the branch is chosen once, at build time.
if tf.reduce_mean(x) > 0:      # a Tensor, always truthy
    y = f(x)
else:
    y = g(x)                    # dead code, never in the graph

The correct form:

y = tf.cond(tf.reduce_mean(x) > 0, lambda: f(x), lambda: g(x))

which brings four real costs. Both branches are traced, so both must be constructible even on inputs they will never see. Shapes and dtypes must match exactly across branches, so a branch returning a different sequence length simply cannot be expressed. Closures capture confusingly, since the lambdas execute at build time and the enclosing Python scope is not what you’d guess. And tf.while_loop needs loop_vars with invariant shapes, so a growing accumulator requires a TensorArray and explicit shape_invariants.

Now compare a Python while in eager mode, which is just a while.

The deeper point is that this is not TF being badly designed — it is what capturing a graph fundamentally requires. Module 4 shows Dynamo hitting the identical wall and choosing differently: rather than forcing you into tf.cond, it breaks the graph at the branch, runs that part in Python, and compiles the pieces on either side. Same constraint; the difference is who absorbs it.

Because it was a leaky abstraction over the same gap, and the leaks showed up as silent bugs rather than errors.

tf.function traces your Python once per input signature and caches the result. That means:

• Python side effects run only during tracing. A print() fires on the first call and never again; a counter increments once. The function silently means something different from what it says.
• Retracing is invisible and expensive. Every new input shape or dtype, or any Python-valued argument, triggers a fresh trace. Pass a Python int that varies and you retrace on every call, turning an optimisation into a large slowdown with no error and no warning.
• AutoGraph rewrote your source. It parsed your Python and converted if/while into tf.cond/tf.while_loop automatically — which worked until it did not, and then you were debugging generated code you never wrote.
• The same shape constraints returned, now hidden inside a decorator that promised they were handled.

So TF2 had eager mode and a graph mode that recreated the original ergonomic problems whenever you used it. Users got a framework that was slow by default and confusing when made fast.

Note carefully that retracing is not a TF-specific mistake — torch.compile has exactly the same failure mode, called recompilation, covered in Module 10. What differs is the handling: PyTorch gives you TORCH_LOGS=recompiles to see it, a cache-size limit that warns and falls back to eager rather than degrading silently, and mark_dynamic to declare intent. The problem is inherent; the observability is the product.

Because the argument is about where you are on the curve, not a blanket ordering, and the industry moved along that curve.

In 2017 the binding constraint was research throughput. Models were small enough to train on a few GPUs, nobody knew which architectures would matter, and the cost of a bad framework choice was measured in graduate-student weeks. Iteration dominated by a wide margin.

By 2023 the picture inverted for a large slice of work. Architectures converged on the transformer, so exploration matters less. Training runs cost millions, so a 30% speed-up is a line item on a budget. Inference runs continuously at scale, so it is pure marginal cost. And model size grew past the point where per-op Python overhead is negligible — at batch 1 decode (Module 3), launch overhead is a large fraction of the step.

So the correct design is not “eager” or “graph”. It is eager by default with graph mode available, opt-in, and escapable, which is precisely torch.compile: one decorator, silent fallback when capture fails, and your real Python underneath.

The framing worth keeping for the rest of the series: TF1 chose the endpoint that was right for the machine, PyTorch chose the one right for the human, and everything since has been an attempt to travel between them without giving up either. Every subsequent module is a piece of that machinery — and Parts M is where the travel is still incomplete.