Progress Bars and Spinners with indicatif

17 min read

Give long-running CLI work a heartbeat: progress bars, spinners, byte counters, and stacked multi-progress displays — all rendered to the terminal with the indicatif crate.

Quick Overview

When a command does real work — downloading files, processing thousands of records, compiling — users want feedback. In Node you reach for cli-progress or ora; in Rust the de-facto choice is indicatif. It draws single bars, animated spinners, and several stacked bars at once, automatically redrawing the terminal in place. Crucially, it knows when its output is not a terminal (a pipe, a CI log) and quietly does nothing, so you never spew thousands of garbled lines into a log file.

Note: This file uses indicatif 0.18 with Rust 1.96.0 on the latest stable edition (2024). The current API centers on ProgressBar, ProgressStyle::with_template, and MultiProgress. The pre-0.17 ProgressStyle::default_bar().template("…") chaining and the old {wide_bar}-only styling are superseded by the with_template(...).unwrap() builder shown throughout.

TypeScript/JavaScript Example

A typical Node CLI that downloads several files, using cli-progress for bars and ora for a spinner:

1
// npm install cli-progress ora
2
import cliProgress from "cli-progress";
3
import ora from "ora";
4

5
// A spinner for an indeterminate step (we don't know how long DNS/handshake takes)
6
const spinner = ora("Resolving dependencies...").start();
7
await new Promise((r) => setTimeout(r, 800));
8
spinner.succeed("Resolved 42 packages");
9

10
// A determinate bar for a download where we know the total size
11
const bar = new cliProgress.SingleBar(
12
  {
13
    format: "Downloading [{bar}] {percentage}% | {value}/{total} bytes",
14
    hideCursor: true,
15
  },
16
  cliProgress.Presets.shades_classic,
17
);
18

19
const total = 5 * 1024 * 1024; // 5 MiB
20
bar.start(total, 0);
21
let downloaded = 0;
22
while (downloaded < total) {
23
  await new Promise((r) => setTimeout(r, 2));
24
  downloaded = Math.min(downloaded + 64 * 1024, total);
25
  bar.update(downloaded);
26
}
27
bar.stop();
28
console.log("Done.");

You manually wire up two different libraries, pass a format string with {bar}/{value}/{total} tokens, and call start/update/stop. Updating multiple bars at once requires cli-progress’s MultiBar.

Rust Equivalent

The same two phases — an indeterminate spinner, then a determinate byte bar — with indicatif:

1
// Cargo.toml: cargo add indicatif
2
use indicatif::{ProgressBar, ProgressStyle};
3
use std::thread;
4
use std::time::Duration;
5

6
fn main() {
7
    // 1. Spinner for an indeterminate step.
8
    let spinner = ProgressBar::new_spinner();
9
    spinner.set_message("Resolving dependencies...");
10
    spinner.enable_steady_tick(Duration::from_millis(80));
11
    thread::sleep(Duration::from_millis(800)); // pretend work
12
    spinner.finish_with_message("Resolved 42 packages");
13

14
    // 2. Determinate bar for a 5 MiB download.
15
    let total_bytes: u64 = 5 * 1024 * 1024;
16
    let pb = ProgressBar::new(total_bytes);
17
    pb.set_style(
18
        ProgressStyle::with_template(
19
            "Downloading [{bar:40.cyan/blue}] {percent}% | {bytes}/{total_bytes}",
20
        )
21
        .unwrap()
22
        .progress_chars("#>-"),
23
    );
24

25
    let chunk = 64 * 1024;
26
    let mut downloaded = 0u64;
27
    while downloaded < total_bytes {
28
        thread::sleep(Duration::from_millis(2)); // pretend network I/O
29
        downloaded = (downloaded + chunk).min(total_bytes);
30
        pb.set_position(downloaded);
31
    }
32
    pb.finish_with_message("Done.");
33
}

While running in a terminal, the bar redraws in place. The final frame looks like:

1
Downloading [########################################] 100% | 5.00 MiB/5.00 MiB

One crate covers both the spinner and the bar, the {bytes}/{total_bytes} tokens format raw byte counts as human-readable units automatically, and (as you’ll see below) the same MultiProgress type handles many bars at once.

Detailed Explanation

Creating a bar

ProgressBar::new(len) builds a determinate bar whose total is len (a u64). ProgressBar::new_spinner() builds an indeterminate spinner with no known total. Both return an owned ProgressBar.

A key fact for the rest of this file: ProgressBar is internally an Arc around shared state, so cloning it is cheap and all clones drive the same on-screen bar. That is why you can move a clone into a thread (shown later) without Arc::new(Mutex::new(...)) ceremony.

Advancing the bar

1
use indicatif::ProgressBar;
2

3
fn main() {
4
    let pb = ProgressBar::new(1000);
5
    pb.inc(1);            // advance by 1 (relative)
6
    pb.inc(10);           // advance by 10 more -> position is 11
7
    pb.set_position(500); // jump to an absolute position
8
    pb.set_length(2000);  // the total can change mid-flight
9
    println!("{}", pb.position()); // read current position: 500
10
    pb.finish();          // leave the completed bar on screen
11
}

inc(delta) is the workhorse: call it once per processed item.
set_position(n) sets an absolute value — ideal when you track bytes downloaded.
set_length(n) adjusts the total if you discover more work later.
A spinner has no length; you just inc(1) or let enable_steady_tick animate it on a timer.

Finishing

How you end a bar matters because it decides what stays on screen:

Method	Effect
`finish()`	Sets position to the length and leaves the full bar visible
`finish_with_message(msg)`	Same, plus sets the `{msg}` field to `msg`
`finish_and_clear()`	Removes the bar entirely (good for transient spinners)
`abandon()` / `abandon_with_message`	Stops redrawing, leaves the bar at its current (partial) position

A spinner that should vanish once its step succeeds uses finish_and_clear:

1
use indicatif::ProgressBar;
2
use std::thread;
3
use std::time::Duration;
4

5
fn main() {
6
    let pb = ProgressBar::new_spinner();
7
    pb.enable_steady_tick(Duration::from_millis(100));
8
    pb.set_message("Fetching metadata...");
9
    thread::sleep(Duration::from_millis(300)); // work
10
    pb.finish_and_clear();
11
    println!("Fetched."); // the spinner line is gone; only this prints
12
}

Styling with templates

ProgressStyle::with_template(s) parses a template string and returns a Result<ProgressStyle, TemplateError> — you must handle (or .unwrap()) it. The template is a sequence of literal text and {token} placeholders. Common tokens:

Token	Renders
`{bar}` / `{bar:40}`	The bar itself; the number sets its width in cells
`{wide_bar}`	A bar that expands to fill the remaining terminal width
`{spinner}`	The animated spinner glyph
`{pos}` / `{len}`	Raw current position / total
`{percent}`	Integer percentage complete
`{bytes}` / `{total_bytes}`	Position / length formatted as `KiB`, `MiB`, …
`{bytes_per_sec}`	Throughput as `… MiB/s`
`{per_sec}`	Items per second
`{elapsed_precise}`	Elapsed wall-clock time `HH:MM:SS`
`{eta}`	Estimated time remaining
`{msg}`	The message set via `set_message` / `finish_with_message`
`{prefix}`	The prefix set via `set_prefix` (handy with multi-progress)

A token can carry a width, an alignment, and a color spec: {bar:40.cyan/blue} means “40 cells wide, filled portion cyan, empty portion blue”; {prefix:>12.green} means “right-aligned in 12 columns, green”. .progress_chars("#>-") chooses the glyphs for the filled cell, the in-progress cell, and the empty cell respectively.

1
use indicatif::ProgressStyle;
2

3
fn main() {
4
    let style = ProgressStyle::with_template(
5
        "{spinner:.green} [{elapsed_precise}] [{bar:40.cyan/blue}] {pos}/{len} ({eta})",
6
    )
7
    .unwrap()
8
    .progress_chars("#>-");
9
    let _ = style; // attach to a bar with pb.set_style(style)
10
}

Iterator and byte-stream adapters

Two ergonomic helpers remove most boilerplate.

ProgressIterator::progress() wraps any iterator with a known length and updates a bar automatically as you consume it:

1
// indicatif's ProgressIterator trait must be in scope
2
use indicatif::ProgressIterator;
3
use std::thread;
4
use std::time::Duration;
5

6
fn main() {
7
    let files = vec!["a.txt", "b.txt", "c.txt", "d.txt"];
8
    for file in files.iter().progress() {
9
        thread::sleep(Duration::from_millis(100)); // process each file
10
        let _ = file;
11
    }
12
} // bar finishes automatically when the iterator is exhausted

ProgressBar::wrap_read (and wrap_write) wraps a reader/writer so every byte that flows through advances the bar — perfect for hashing or copying a file with byte-accurate progress (see the Real-World Example).

`{bytes}` and the `Human*` helpers

The same human-formatting logic behind {bytes} is exposed as standalone Display types you can use anywhere — in println!, in logs, or to build your own messages:

1
use indicatif::{HumanBytes, HumanCount, HumanDuration};
2
use std::time::Duration;
3

4
fn main() {
5
    println!("{}", HumanBytes(1_500_000));            // 1.43 MiB
6
    println!("{}", HumanCount(1_234_567));            // 1,234,567
7
    println!("{}", HumanDuration(Duration::from_secs(95))); // 2 minutes
8
}

Real output:

1
1.43 MiB
2
1,234,567
3
2 minutes

Key Differences

Concern	Node (`cli-progress` / `ora`)	Rust (`indicatif`)
Bars + spinners	Two separate libraries	One crate; `ProgressBar` and `ProgressBar::new_spinner()`
Template tokens	`{bar} {value} {total} {percentage}`	`{bar} {pos} {len} {percent} {bytes} {eta} …` (richer set)
Byte formatting	Manual (`prettyBytes(value)`)	Built in: `{bytes}`, `{bytes_per_sec}`, `HumanBytes`
Multiple bars	`MultiBar`	`MultiProgress`
Animation timing	Spinner auto-animates on a timer	Opt in with `enable_steady_tick(interval)`; otherwise you `tick()`
Non-TTY behavior	May still print lines unless you guard it	Auto-detects: a piped/redirected target draws nothing
Sharing across concurrency	Single-threaded event loop; just close over the bar	`ProgressBar` is `Arc`-backed and `Send + Sync` — clone into threads
Error handling on bad template	Throws at runtime	`with_template` returns a `Result` you must handle at compile time

The two deepest differences for a TypeScript/JavaScript developer:

Concurrency is real here. Node’s bars live on one event loop. In Rust you typically spawn OS threads (or use rayon), and indicatif is designed for it: clone the bar (or use MultiProgress) and update from many threads safely. There is no single-threaded assumption to fall back on.
Templates are validated up front. with_template hands you a Result. A malformed template surfaces as a TemplateError you decide how to handle, rather than silently printing the wrong thing.

Common Pitfalls

Pitfall 1: Forgetting that `with_template` returns a `Result`

set_style wants a ProgressStyle, but with_template gives you a Result<ProgressStyle, TemplateError>. Passing it directly fails to compile:

1
use indicatif::{ProgressBar, ProgressStyle};
2

3
fn main() {
4
    let pb = ProgressBar::new(100);
5
    // does not compile (error[E0308]: mismatched types)
6
    pb.set_style(ProgressStyle::with_template("[{bar}] {pos}/{len}"));
7
}

The real compiler error:

1
error[E0308]: mismatched types
2
 --> src/main.rs:6:18
3
  |
4
6 |     pb.set_style(ProgressStyle::with_template("[{bar}] {pos}/{len}"));
5
  |        --------- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `ProgressStyle`, found `Result<ProgressStyle, TemplateError>`
6
  |        |
7
  |        arguments to this method are incorrect
8
  |
9
  = note: expected struct `ProgressStyle`
10
               found enum `Result<ProgressStyle, TemplateError>`
11
help: consider using `Result::expect` to unwrap the `Result<ProgressStyle, TemplateError>` value, panicking if the value is a `Result::Err`

Fix: .unwrap() (templates are usually constant, so a panic on a typo at startup is acceptable) or propagate the error with ?:

1
use indicatif::{ProgressBar, ProgressStyle};
2

3
fn main() {
4
    let pb = ProgressBar::new(100);
5
    pb.set_style(ProgressStyle::with_template("[{bar}] {pos}/{len}").unwrap()); //
6
}

Pitfall 2: Using `println!` while a bar is on screen

A live bar owns the bottom line of the terminal. A raw println! writes over it and leaves a garbled, doubled-up display. Route your output through the bar instead:

1
use indicatif::ProgressBar;
2
use std::thread;
3
use std::time::Duration;
4

5
fn main() {
6
    let pb = ProgressBar::new(5);
7
    for i in 0..5 {
8
        thread::sleep(Duration::from_millis(50));
9
        // pb.println prints above the bar, then redraws the bar intact
10
        pb.println(format!("processed item {i}"));
11
        pb.inc(1);
12
    }
13
    pb.finish_with_message("done");
14
}

For arbitrary code that prints (a logging macro, a library call) wrap it in suspend, which clears the bar, runs the closure, and redraws:

1
use indicatif::ProgressBar;
2
use std::thread;
3
use std::time::Duration;
4

5
fn main() {
6
    let pb = ProgressBar::new(3);
7
    pb.set_message("working");
8
    for _ in 0..3 {
9
        pb.suspend(|| {
10
            println!("a normal log line printed safely");
11
        });
12
        thread::sleep(Duration::from_millis(20));
13
        pb.inc(1);
14
    }
15
    pb.finish();
16
}

Tip: If you use the tracing or log ecosystems, the indicatif-aware logger bridges exist (e.g. tracing-indicatif) so your structured logs and your bars coexist without manual suspend calls.

Pitfall 3: The bar “doesn’t show up” in CI or when piped

This is by design, not a bug. indicatif detects that stderr is not an interactive terminal and switches to a hidden draw target, so it produces no output when piped to a file or run in CI. To confirm your logic without a terminal, build a hidden bar explicitly — the API still works, which makes bars easy to keep in code paths that are also unit-tested:

1
use indicatif::ProgressBar;
2

3
fn main() {
4
    let pb = ProgressBar::hidden(); // never draws, but tracks state
5
    pb.inc(10);
6
    assert_eq!(pb.position(), 10);  // logic is exercisable without a TTY
7
}

If you genuinely want progress in a non-TTY context (a log you watch with tail), set an explicit draw target with ProgressBar::with_draw_target / set_draw_target using ProgressDrawTarget::stderr().

Pitfall 4: A spinner that never moves

A spinner only animates when something advances it. If your work is one long blocking call, you never call tick(), so the spinner freezes. Use enable_steady_tick(interval) to animate it on a background timer regardless of your work loop:

1
use indicatif::ProgressBar;
2
use std::time::Duration;
3

4
fn main() {
5
    let pb = ProgressBar::new_spinner();
6
    pb.enable_steady_tick(Duration::from_millis(80)); // animates on its own
7
    // ... do one long blocking thing ...
8
    pb.finish_and_clear();
9
}

Best Practices

Draw to stderr (the default). Bars belong on stderr so a user can still pipe your program’s real stdout output elsewhere without bar noise. indicatif’s default draw target is already stderr — don’t move it to stdout.
Build the style once, clone it for many bars. ProgressStyle is cheap to clone(); construct it a single time and hand a clone to each bar in a MultiProgress.
Set a reasonable redraw rate. The default throttles redraws, but for tight loops with millions of iterations, pb.set_draw_target(ProgressDrawTarget::stderr_with_hz(10)) or batching inc calls avoids spending all your time redrawing.
Prefer the adapters. iterator.progress() and pb.wrap_read(reader) eliminate manual inc/set_position calls and are harder to get wrong.
Always finish the bar. Call finish* (or finish_and_clear for spinners) so the cursor and terminal state are restored cleanly. Leaving a bar un-finished can leave the cursor hidden.
Use {wide_bar} for the main bar so it adapts to terminal width, and reserve fixed {bar:N} widths for stacked multi-progress rows where alignment matters.

Real-World Example

A production-flavored task: walk a file, hash-or-process it with byte-accurate progress by wrapping the reader, then report throughput. This mirrors what sha256sum-style or backup tools display.

1
// Cargo.toml: cargo add indicatif
2
use indicatif::{ProgressBar, ProgressStyle};
3
use std::fs;
4
use std::io::{self, Read, Write};
5

6
fn main() -> io::Result<()> {
7
    // Set up a 2 MiB sample file to "process".
8
    let dir = std::env::temp_dir().join("indicatif_demo");
9
    fs::create_dir_all(&dir)?;
10
    let path = dir.join("data.bin");
11
    fs::write(&path, vec![0u8; 2 * 1024 * 1024])?;
12

13
    let len = fs::metadata(&path)?.len();
14
    let pb = ProgressBar::new(len);
15
    pb.set_style(
16
        ProgressStyle::with_template(
17
            "[{elapsed_precise}] [{bar:40.green/black}] \
18
             {bytes}/{total_bytes} ({bytes_per_sec})",
19
        )
20
        .unwrap()
21
        .progress_chars("##-"),
22
    );
23

24
    // wrap_read advances the bar by every byte read — no manual inc() needed.
25
    let file = fs::File::open(&path)?;
26
    let mut reader = pb.wrap_read(file);
27
    let mut sink = io::sink(); // stand-in for a hasher or destination file
28
    let mut buf = [0u8; 8192];
29
    loop {
30
        let n = reader.read(&mut buf)?;
31
        if n == 0 {
32
            break;
33
        }
34
        sink.write_all(&buf[..n])?;
35
    }
36

37
    pb.finish_with_message("hashed");
38
    fs::remove_dir_all(&dir)?;
39
    println!("processed {len} bytes");
40
    Ok(())
41
}

Running this in a terminal redraws a green byte bar that fills as the file is read; the program then prints processed 2097152 bytes. The byte counter, throughput, and elapsed time all come “for free” from the template tokens because wrap_read feeds the bar.

Stacked bars for concurrent work

When several tasks run on their own threads, MultiProgress keeps each on its own line and redraws them as a group. Because ProgressBar is Arc-backed, you simply move each bar into its thread:

1
// Cargo.toml: cargo add indicatif
2
use indicatif::{MultiProgress, ProgressBar, ProgressStyle};
3
use std::thread;
4
use std::time::Duration;
5

6
fn main() {
7
    let multi = MultiProgress::new();
8
    let style = ProgressStyle::with_template("{prefix:>12.cyan} [{bar:30}] {pos}/{len}")
9
        .unwrap()
10
        .progress_chars("=> ");
11

12
    let mut handles = Vec::new();
13
    for i in 0..3 {
14
        let pb = multi.add(ProgressBar::new(100)); // registered with the group
15
        pb.set_style(style.clone());               // reuse one style
16
        pb.set_prefix(format!("task-{i}"));
17
        handles.push(thread::spawn(move || {
18
            for _ in 0..100 {
19
                thread::sleep(Duration::from_millis(3 + i * 2));
20
                pb.inc(1);
21
            }
22
            pb.finish_with_message("done");
23
        }));
24
    }
25
    for h in handles {
26
        h.join().unwrap();
27
    }
28
}

In a terminal this renders three independently advancing bars stacked vertically, each prefixed task-0 … task-2, all redrawing in place until every thread joins.

Parallel iteration with `rayon`

If you already use rayon for data parallelism, enable indicatif’s rayon feature and wrap a parallel iterator the same way you wrap a sequential one:

1
[dependencies]
2
indicatif = { version = "0.18", features = ["rayon"] }
3
rayon = "1"

1
use indicatif::ParallelProgressIterator; // gated behind the "rayon" feature
2
use rayon::prelude::*;
3
use std::thread;
4
use std::time::Duration;
5

6
fn main() {
7
    let items: Vec<u64> = (0..200).collect();
8
    let sum: u64 = items
9
        .par_iter()
10
        .progress_count(items.len() as u64) // a thread-safe shared bar
11
        .map(|n| {
12
            thread::sleep(Duration::from_millis(5)); // pretend per-item work
13
            n * 2
14
        })
15
        .sum();
16
    println!("sum = {sum}");
17
}

Real output:

1
sum = 39800

Warning: ParallelProgressIterator is only exported when the rayon feature is enabled. Without it you get error[E0432]: unresolved import indicatif::ParallelProgressIterator and a note that the item is “configured out” by the rayon feature gate. Add the feature in Cargo.toml as shown.

Exercises

Exercise 1: A styled determinate bar

Difficulty: Beginner

Objective: Build a bar with a custom template and advance it in a loop.

Instructions: Create a ProgressBar for 50 units of work. Give it a style whose template shows a 30-cell cyan bar followed by {pos}/{len} and the ETA. Advance it by 1 each iteration with a short sleep, then finish with the message complete.

1
use indicatif::{ProgressBar, ProgressStyle};
2
use std::thread;
3
use std::time::Duration;
4

5
fn main() {
6
    let pb = ProgressBar::new(50);
7
    // TODO: set a style with template "[{bar:30.cyan/blue}] {pos}/{len} ({eta})"
8
    for _ in 0..50 {
9
        thread::sleep(Duration::from_millis(20));
10
        // TODO: advance the bar
11
    }
12
    // TODO: finish with the message "complete"
13
}

Solution

1
use indicatif::{ProgressBar, ProgressStyle};
2
use std::thread;
3
use std::time::Duration;
4

5
fn main() {
6
    let pb = ProgressBar::new(50);
7
    pb.set_style(
8
        ProgressStyle::with_template("[{bar:30.cyan/blue}] {pos}/{len} ({eta})")
9
            .unwrap()
10
            .progress_chars("#>-"),
11
    );
12
    for _ in 0..50 {
13
        thread::sleep(Duration::from_millis(20));
14
        pb.inc(1);
15
    }
16
    pb.finish_with_message("complete");
17
}

Exercise 2: A self-animating spinner

Difficulty: Intermediate

Objective: Show an indeterminate spinner that animates during one blocking step, then clears itself.

Instructions: Create a spinner, give it a custom set of tick glyphs, set the message Connecting..., enable a steady tick of 80 ms, sleep ~600 ms to simulate a blocking connection, then change the message to Authenticating..., sleep again, and finally finish_and_clear so no spinner line is left behind. Print Connected. afterward.

1
use indicatif::{ProgressBar, ProgressStyle};
2
use std::thread;
3
use std::time::Duration;
4

5
fn main() {
6
    let spinner = ProgressBar::new_spinner();
7
    // TODO: style with tick_strings, enable steady tick, drive two phases, clear
8
}

Solution

1
use indicatif::{ProgressBar, ProgressStyle};
2
use std::thread;
3
use std::time::Duration;
4

5
fn main() {
6
    let spinner = ProgressBar::new_spinner();
7
    spinner.set_style(
8
        ProgressStyle::with_template("{spinner:.green} {msg}")
9
            .unwrap()
10
            .tick_strings(&["⠋", "⠙", "⠹", "⠸", "⠼", "⠴", "⠦", "⠧", "⠇", "⠏"]),
11
    );
12
    spinner.enable_steady_tick(Duration::from_millis(80));
13

14
    spinner.set_message("Connecting...");
15
    thread::sleep(Duration::from_millis(600));
16

17
    spinner.set_message("Authenticating...");
18
    thread::sleep(Duration::from_millis(600));
19

20
    spinner.finish_and_clear();
21
    println!("Connected.");
22
}

Exercise 3: Concurrent multi-progress downloads

Difficulty: Advanced

Objective: Drive several bars at once from separate threads using MultiProgress, with differently sized “downloads” measured in bytes.

Instructions: Write a helper download(multi, name, size, style) that adds a bar to a shared MultiProgress, sets its prefix to name and style to the shared style, then spawns a thread that advances the bar in 4 KiB chunks until it reaches size, finishing with a done message. In main, build a byte-oriented style ({prefix} [{bar}] {bytes}/{total_bytes}), launch three downloads of different sizes, join all threads, and print All downloads finished.

1
use indicatif::{MultiProgress, ProgressBar, ProgressStyle};
2
use std::thread;
3
use std::time::Duration;
4

5
// TODO: fn download(...) -> thread::JoinHandle<()> { ... }
6

7
fn main() {
8
    let multi = MultiProgress::new();
9
    // TODO: build style, spawn three downloads, join, print summary
10
}

Solution

1
use indicatif::{MultiProgress, ProgressBar, ProgressStyle};
2
use std::thread;
3
use std::time::Duration;
4

5
fn download(
6
    multi: &MultiProgress,
7
    name: &str,
8
    size: u64,
9
    style: &ProgressStyle,
10
) -> thread::JoinHandle<()> {
11
    let pb = multi.add(ProgressBar::new(size));
12
    pb.set_style(style.clone());
13
    pb.set_prefix(name.to_string());
14
    thread::spawn(move || {
15
        let mut done = 0;
16
        while done < size {
17
            thread::sleep(Duration::from_millis(4)); // pretend network I/O
18
            done = (done + 4096).min(size);
19
            pb.set_position(done);
20
        }
21
        pb.finish_with_message("done");
22
    })
23
}
24

25
fn main() {
26
    let multi = MultiProgress::new();
27
    let style = ProgressStyle::with_template(
28
        "{prefix:<14} [{bar:25.cyan/blue}] {bytes}/{total_bytes}",
29
    )
30
    .unwrap()
31
    .progress_chars("=> ");
32

33
    let handles = vec![
34
        download(&multi, "core.tar.gz", 300 * 1024, &style),
35
        download(&multi, "docs.tar.gz", 120 * 1024, &style),
36
        download(&multi, "extras.tar.gz", 500 * 1024, &style),
37
    ];
38
    for h in handles {
39
        h.join().unwrap();
40
    }
41
    println!("All downloads finished");
42
}

Progress Bars and Spinners with indicatif

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

Creating a bar

Advancing the bar

Finishing

Styling with templates

Iterator and byte-stream adapters

{bytes} and the Human* helpers

Key Differences

Common Pitfalls

Pitfall 1: Forgetting that with_template returns a Result

Pitfall 2: Using println! while a bar is on screen

Pitfall 3: The bar “doesn’t show up” in CI or when piped

Pitfall 4: A spinner that never moves

Best Practices

Real-World Example

Stacked bars for concurrent work

Parallel iteration with rayon

Further Reading

Exercises

Exercise 1: A styled determinate bar

Exercise 2: A self-animating spinner

Exercise 3: Concurrent multi-progress downloads

`{bytes}` and the `Human*` helpers

Pitfall 1: Forgetting that `with_template` returns a `Result`

Pitfall 2: Using `println!` while a bar is on screen

Parallel iteration with `rayon`