Julia and Jupyter Notebooks

Analogy categoryAnalogies

Running Julia in Jupyter with IJulia

The "Ju" in Jupyter literally stands for Julia (alongside Python and R), and the IJulia.jl package provides the Julia kernel that lets Jupyter Notebook or JupyterLab execute Julia code cells, complete with rich output rendering for plots, LaTeX-formatted math, and Markdown cells interleaved with code. Installing it is as simple as using Pkg; Pkg.add("IJulia"), after which using IJulia; notebook() launches Jupyter with the Julia kernel registered and selectable, or you can select "Julia" as the kernel from an existing JupyterLab installation that has been pointed at your Julia installation's kernel spec.

🏏

Cricket analogy: It's like the ICC allowing three formats — Test, ODI, T20 — to be officiated under one shared umpiring panel and ground infrastructure; IJulia lets Julia plug into the same Jupyter infrastructure that Python and R already use.

julia

using Pkg
Pkg.add("IJulia")

using IJulia
notebook(dir="~/projects/my_analysis")  # launches Jupyter in the given directory

# Inside a notebook cell, once the Julia kernel is selected:
using Plots
x = 0:0.1:2π
plot(x, sin.(x), label="sin(x)", lw=2)

If you have multiple Julia versions installed, each one registers its own separate Jupyter kernel (e.g. "Julia 1.10" and "Julia 1.11"), letting you pick the exact version per notebook from the kernel selector rather than being locked to whichever Julia is on your PATH.

Pluto.jl: Reactive Notebooks

Pluto.jl takes a fundamentally different approach from Jupyter's linear, mutable-state execution model: a Pluto notebook is "reactive," meaning it tracks data dependencies between cells and automatically re-runs every cell downstream of one you edit, so the notebook can never silently drift out of sync with what's displayed — a problem notorious in Jupyter, where running cells out of order (or re-running an earlier cell after editing a later one) leaves stale variables in memory that don't match what's on screen. This reactivity comes with a strict rule: a Pluto notebook cannot define the same variable in two different cells, because the dependency graph needs each variable's definition to be unambiguous, which pushes you toward cleaner, more explicit notebook structure than Jupyter typically enforces.

🏏

Cricket analogy: It's like a DRS system that automatically re-checks every subsequent decision in the over if an earlier lbw call is overturned, rather than a manual scorer who might forget to update later entries — Pluto propagates changes downstream automatically.

julia

### A minimal Pluto.jl notebook cell structure (each ### begins a cell)

### cell 1
using Pluto, Plots

### cell 2
n = 50

### cell 3 (automatically re-runs whenever `n` changes in cell 2)
x = range(0, 4π, length=n)
y = sin.(x)

### cell 4 (automatically re-runs whenever `x` or `y` change)
plot(x, y, title="sin curve with n=$n points")

Choosing Between Jupyter and Pluto

Jupyter/IJulia is the better choice when you need broad ecosystem compatibility — sharing notebooks with colleagues using Python or R, running on JupyterHub in a shared institutional environment, or using the vast library of Jupyter extensions for widgets, slideshows, and nbconvert-based exports to PDF or HTML. Pluto is the better choice for teaching, reproducible exploratory analysis, and interactive dashboards, because its reactivity guarantees the notebook state always matches what's on screen, and because a Pluto notebook file is itself just a plain .jl Julia file with embedded cell markers, meaning it can be version-controlled with meaningful diffs and even run as a plain script outside the notebook environment.

🏏

Cricket analogy: It's like choosing between the ICC's global multi-format calendar (broad compatibility across boards) and a domestic franchise league's tightly-controlled single format (Jupyter's broad reach versus Pluto's guaranteed internal consistency).

In classic Jupyter/IJulia, re-running cells out of order is a common source of confusing bugs: a variable can still hold a value from a cell you've since deleted or edited, because Jupyter's kernel state is just whatever cells happened to run, in whatever order you ran them. Always test with 'Restart Kernel and Run All' before trusting or sharing a Jupyter notebook's results.

IJulia.jl provides the Julia kernel for Jupyter Notebook/JupyterLab, installed via Pkg.add("IJulia") and launched with notebook().
Multiple installed Julia versions each register their own separate Jupyter kernel, selectable per notebook.
Pluto.jl is a reactive notebook: editing a cell automatically re-runs every cell that depends on it, keeping state and display in sync.
Pluto disallows defining the same variable in two cells, enforcing an unambiguous dependency graph.
A Pluto notebook file is a plain .jl file with cell markers, making it diff-friendly in version control and runnable as a script.
Jupyter/IJulia wins for cross-language sharing, JupyterHub environments, and the broad extension ecosystem.
Always use 'Restart Kernel and Run All' in Jupyter before trusting results, since out-of-order execution can leave stale state.