Move, Copy, and Clone

20 min read

In TypeScript and JavaScript, assigning one variable to another never duplicates the underlying object — both names point at the same garbage-collected value, and you rarely think about who owns what. Rust replaces that quiet sharing with three precise behaviors: a value is moved (ownership transfers, the old name becomes unusable), copied (a cheap bit-for-bit duplicate of a stack value), or cloned (an explicit, possibly expensive deep duplicate). Understanding which one happens — and when — is the difference between fighting the compiler and writing fluent Rust.

Quick Overview

When you write let b = a; in Rust, one of two things happens: if a’s type implements the Copy trait (small, stack-only values like i32 or bool), a is duplicated and both a and b stay usable; otherwise the value is moved — b takes ownership and a becomes inaccessible. To get a duplicate of a non-Copy value (like a String or Vec), you call .clone() explicitly, which performs a deep copy you can see in the source. This is the opposite of JavaScript, where const b = a for an object simply aliases the same heap value and the GC keeps it alive for as long as anyone references it.

Note: This page builds directly on Ownership Rules (each value has one owner; assignment moves it) and Stack vs Heap (why some types are cheap to copy and others are not). If those ideas are new, skim them first.

TypeScript/JavaScript Example

In JavaScript, every variable holding an object holds a reference. Assignment copies the reference, never the object, and primitives are copied by value. You never explicitly “move” or “clone” — the engine and garbage collector handle lifetime for you.

1
interface Product {
2
  sku: string;
3
  tags: string[];
4
}
5

6
// Assigning an object copies the REFERENCE, not the object.
7
const original: Product = { sku: "A-100", tags: ["new"] };
8
const alias = original;
9
alias.tags.push("sale");
10
console.log(original.tags); // [ 'new', 'sale' ] — they are the SAME object
11

12
// Primitives are copied by value.
13
let count = 5;
14
let backup = count;
15
backup += 1;
16
console.log(count, backup); // 5 6 — independent copies
17

18
// To get a genuinely separate object you must clone EXPLICITLY,
19
// and even then a shallow clone shares nested arrays/objects.
20
const shallow = { ...original };
21
const deep = structuredClone(original);
22
shallow.tags.push("shallow"); // mutates original.tags too!
23
deep.tags.push("deep"); // safe: deep has its own array
24
console.log(original.tags); // [ 'new', 'sale', 'shallow' ]
25
console.log(deep.tags); // [ 'new', 'sale', 'deep' ]
26

27
// Passing an object to a function passes the reference; the original
28
// is still usable afterward, and mutations leak back to the caller.
29
function addTag(p: Product, tag: string): void {
30
  p.tags.push(tag);
31
}
32
addTag(original, "fn"); // original is fine after the call

What the runtime does for you here:

const alias = original aliases the same heap object. Both names see each other’s mutations.
let backup = count copies the primitive 5. The two numbers are independent.
After passing original to addTag, you can keep using original — the function only borrowed a reference, and the GC keeps the object alive.

Rust makes every one of these distinctions explicit and enforces them at compile time.

Rust Equivalent

The same three behaviors — alias-by-reference, copy-by-value, and explicit deep copy — become move, Copy, and Clone:

1
#[derive(Debug, Clone)]
2
struct Account {
3
    id: u64,
4
    owner: String,
5
    balance: f64,
6
}
7

8
// Takes ownership of `account` (it is MOVED in), mutates it, and returns it.
9
fn deposit(mut account: Account, amount: f64) -> Account {
10
    account.balance += amount;
11
    account
12
}
13

14
fn main() {
15
    // --- Copy: i32 is a small stack value, so `=` duplicates it. ---
16
    let x = 5;
17
    let y = x; // x is COPIED, not moved
18
    println!("x = {x}, y = {y}"); // both usable
19

20
    // --- Move: String owns heap data, so `=` transfers ownership. ---
21
    let s1 = String::from("hello");
22
    let s2 = s1; // s1 is MOVED into s2
23
    println!("{s2}");
24
    // println!("{s1}"); // does not compile (error[E0382]): s1 was moved
25

26
    // --- Clone: ask explicitly for a deep copy. ---
27
    let s3 = String::from("world");
28
    let s4 = s3.clone(); // duplicates the heap buffer
29
    println!("{s3} {s4}"); // BOTH valid
30

31
    // --- Move into a function and get ownership back via the return. ---
32
    let acct = Account { id: 1, owner: String::from("Ada"), balance: 100.0 };
33
    let acct = deposit(acct, 50.0); // `acct` moved in, rebound to the result
34
    println!("{acct:?}");
35

36
    // --- Clone a whole struct (deep-copies the String inside). ---
37
    let original = Account { id: 2, owner: String::from("Bob"), balance: 0.0 };
38
    let copy = original.clone();
39
    println!("{}", original.owner); // original still usable
40
    println!("{}", copy.owner);
41
}

This compiles and prints:

1
x = 5, y = 5
2
hello
3
world world
4
Account { id: 1, owner: "Ada", balance: 150.0 }
5
Bob
6
Bob

Notice what is visible in the source: every potentially expensive duplication is a .clone() call you can grep for, and every place a value becomes unusable is an ordinary = or function call. There is no hidden deep-copy and no hidden aliasing.

Detailed Explanation

Move: the default for owned, heap-backed values

A String is a three-word handle on the stack — a pointer to a heap buffer, a length, and a capacity (see Stack vs Heap). When you write let s2 = s1;, Rust copies those three stack words into s2. But now two handles would point at the same heap buffer, and when both went out of scope they would each try to free it — a double-free. Rust’s solution is the move: after the assignment, s1 is statically marked invalid, so only s2 is responsible for the buffer. The copy of the stack handle is cheap; what is forbidden is continuing to use the old name.

This is the single biggest mental shift from JavaScript. In JS, const s2 = s1 gives you a second name for the same live object. In Rust, the second name takes over and the first is retired.

Copy: opting out of move for cheap stack values

Some types are so cheap to duplicate that moving them would be pointless ceremony. Integers, floats, bool, char, and tuples/arrays of such types implement the Copy trait. For these, let y = x; performs a bitwise copy and leaves x fully usable — exactly like a JavaScript primitive:

1
fn square(n: i32) -> i32 {
2
    n * n
3
}
4

5
fn main() {
6
    let n = 7;
7
    let sq = square(n); // n is COPIED into the function
8
    println!("{n} squared is {sq}"); // n still usable
9
}

1
7 squared is 49

A type can be Copy only if all of its parts are Copy and it does not own a heap allocation or any other resource. That is why String (owns heap memory) and Vec<T> are not Copy, while (i32, bool) is.

Clone: explicit, deep, possibly expensive

Copy happens implicitly because it is guaranteed cheap. Anything that might be expensive — duplicating a heap buffer, recursively copying a tree — must be requested with .clone(). String::clone allocates a new buffer and copies the bytes; Vec::clone allocates a new array and clones each element. The cost is real, so Rust makes you write it down.

1
let words = vec![String::from("a"), String::from("b")];
2
// `iter()` borrows; `cloned()` clones each &String into an owned String.
3
let joined: String = words.iter().cloned().collect::<Vec<_>>().join("-");
4
println!("{joined}");                 // a-b
5
println!("still have words: {words:?}"); // words was only borrowed, still valid

1
a-b
2
still have words: ["a", "b"]

Moving into functions (and getting ownership back)

Passing a non-Copy value to a function moves it, just like assignment. The function now owns it; the caller does not. If the caller still needs the value, the idiomatic options are (in rough order of preference): borrow instead of moving (&T, covered in Borrowing), return the value back out of the function (as deposit does above), or clone before the call. Borrowing is almost always the right answer when the function only needs to read or temporarily mutate the data.

Partial moves out of a struct

You can move a single field out of a struct. After that, the field is invalid but Copy fields remain readable:

1
#[derive(Debug)]
2
struct Profile {
3
    username: String,
4
    age: u32,
5
}
6

7
fn main() {
8
    let p = Profile { username: String::from("rustacean"), age: 30 };
9
    let name = p.username; // partial MOVE of the String field out of p
10
    let age = p.age;       // u32 is Copy, so this is a copy
11
    println!("{name} is {age}");
12
    // println!("{:?}", p); // does not compile: p is partially moved
13
}

1
rustacean is 30

Key Differences

Aspect	TypeScript/JavaScript	Rust
`let b = a` for an object	Copies the reference; both names alias one live object	Moves ownership; `a` becomes unusable (unless the type is `Copy`)
`let b = a` for a number	Copies the value; both independent	Copies (`Copy` types); both independent
Deep duplicate	`structuredClone(a)` / spread (shallow)	`a.clone()` (depth depends on the type’s `Clone` impl)
Passing to a function	Passes a reference (objects) or a copy (primitives); original stays usable	Moves the value in (non-`Copy`), or copies it (`Copy`); to keep it, borrow or clone
Who frees the memory	The garbage collector, eventually	The single current owner, deterministically at end of scope (Drop)
Cost of duplication	Invisible; sharing is implicit and free	Explicit: cheap `Copy` is automatic, expensive `Clone` is spelled out

The deepest difference is honesty about cost. JavaScript hides whether you are sharing or copying; the GC papers over the lifetime question entirely. Rust forces the choice into the open: a move is a cheap ownership transfer, a Copy is a guaranteed-cheap duplicate, and a Clone is the one place where an allocation might happen — and it is always visible in the source.

Tip: A quick rule of thumb — if a type is Copy, treating it like a JavaScript primitive (free to duplicate, no aliasing surprises) is exactly right. If it is not Copy, assume = and function calls consume the value unless you borrow with &.

Common Pitfalls

Pitfall 1: Using a value after it was moved

This is the error every TypeScript developer hits first, because in JavaScript the original would still be valid:

1
fn main() {
2
    let s1 = String::from("hello");
3
    let s2 = s1; // value moved here
4
    println!("{s1}"); // does not compile (error[E0382])
5
    println!("{s2}");
6
}

The real compiler output:

1
error[E0382]: borrow of moved value: `s1`
2
 --> src/main.rs:4:16
3
  |
4
2 |     let s1 = String::from("hello");
5
  |         -- move occurs because `s1` has type `String`, which does not implement the `Copy` trait
6
3 |     let s2 = s1;
7
  |              -- value moved here
8
4 |     println!("{s1}");
9
  |                ^^ value borrowed here after move
10
  |
11
  = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
12
help: consider cloning the value if the performance cost is acceptable
13
  |
14
3 |     let s2 = s1.clone();
15
  |                ++++++++

The fix is whichever matches your intent: let s2 = s1.clone(); if you genuinely need two owners, or let s2 = &s1; if you only need a second view (Borrowing).

Pitfall 2: Moving a value into a function, then using it again

Same error, but it surprises people because the move is hidden inside a call:

1
fn print_len(s: String) {
2
    println!("{}", s.len());
3
}
4

5
fn main() {
6
    let name = String::from("Grace Hopper");
7
    print_len(name);   // value moved here
8
    println!("{name}"); // does not compile (error[E0382])
9
}

The real output even tells you the better design:

1
error[E0382]: borrow of moved value: `name`
2
 --> src/main.rs:8:16
3
  |
4
6 |     let name = String::from("Grace Hopper");
5
  |         ---- move occurs because `name` has type `String`, which does not implement the `Copy` trait
6
7 |     print_len(name);
7
  |               ---- value moved here
8
8 |     println!("{name}");
9
  |                ^^^^ value borrowed here after move
10
  |
11
note: consider changing this parameter type in function `print_len` to borrow instead if owning the value isn't necessary
12
 --> src/main.rs:1:17
13
  |
14
1 | fn print_len(s: String) {
15
  |    ---------    ^^^^^^ this parameter takes ownership of the value
16
  |    |
17
  |    in this function
18
  = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
19
help: consider cloning the value if the performance cost is acceptable
20
  |
21
7 |     print_len(name.clone());
22
  |                   ++++++++

The idiomatic fix is to make print_len borrow: fn print_len(s: &str) and call print_len(&name). The function never needed to own the string.

Pitfall 3: Deriving `Copy` on a type that owns heap data

You cannot make a String-holding struct Copy, because copying it bit-for-bit would create two owners of one buffer — exactly what move semantics prevent:

1
#[derive(Copy, Clone)] // does not compile (error[E0204])
2
struct Wrapper {
3
    name: String,
4
}

1
error[E0204]: the trait `Copy` cannot be implemented for this type
2
 --> src/main.rs:1:10
3
  |
4
1 | #[derive(Copy, Clone)]
5
  |          ^^^^
6
2 | struct Wrapper {
7
3 |     name: String,
8
  |     ------------ this field does not implement `Copy`

The fix: derive only Clone (#[derive(Clone)]) and call .clone() when you need a duplicate.

Pitfall 4: Reaching for the whole struct after a partial move

Moving one field out invalidates the whole binding for purposes of using it as a unit:

1
let _name = p.username; // moves the String field out
2
println!("{:?}", p);     // does not compile

1
error[E0382]: borrow of partially moved value: `p`
2
  --> src/main.rs:10:22
3
   |
4
 9 |     let _name = p.username;
5
   |                 ---------- value partially moved here
6
10 |     println!("{:?}", p);
7
   |                      ^ value borrowed here after partial move
8
   |
9
   = note: partial move occurs because `p.username` has type `String`, which does not implement the `Copy` trait
10
   = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)

If you need both the field and the rest of the struct, clone the field (p.username.clone()) or borrow it (&p.username).

Pitfall 5: “Cloning” to silence the borrow checker

When the compiler suggests .clone(), it is one valid fix — but reaching for it reflexively can hide a design that should borrow instead, adding needless allocations on a hot path. Clone is a tool, not a panic button. Prefer borrowing first (see Borrowing); clone when you genuinely need two independent owners.

Best Practices

Borrow before you clone before you move. If a function only reads, take &T. If it temporarily mutates, take &mut T. Move (take T) only when the function truly needs to own and store the value. Reserve .clone() for when you genuinely need a second independent owner.
Derive Copy for small, plain value types — IDs, coordinates, enums without data, fixed-size numeric wrappers. It makes them ergonomic to pass around exactly like JavaScript primitives. Always derive Clone alongside Copy (#[derive(Clone, Copy)]); Copy requires Clone as a supertrait.
Never derive Copy on anything that owns a heap allocation or other resource (String, Vec, Box, file handles). Those are move-only by design.
Make clones visible and intentional. When you do clone, a brief comment on why (e.g. “config is shared across threads”) helps reviewers distinguish a deliberate clone from a borrow-checker workaround.
Return ownership instead of cloning when a function transforms a value. The deposit pattern (value in → modified value out) avoids both a clone and a borrow dance.
Reach for Rc/Arc for shared ownership, not repeated .clone() of large data. When many parts of a program need to share one immutable value, reference counting is cheaper than deep cloning — see Reference Counting.

Real-World Example

A job-processing loop shows all three behaviors working together: a Copy ID type passed freely, a shared Config that is only borrowed (never cloned), and jobs that are moved into the processor and consumed.

1
use std::collections::HashMap;
2

3
/// Shared, read-only configuration loaded once at startup.
4
#[derive(Debug, Clone)]
5
struct Config {
6
    service_name: String,
7
    max_retries: u32,
8
    endpoints: Vec<String>,
9
}
10

11
/// A small, all-`Copy` value: cheap to pass and store by value.
12
#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
13
struct JobId(u64);
14

15
#[derive(Debug)]
16
struct Job {
17
    id: JobId,
18
    payload: String,
19
}
20

21
/// Consumes the job (it is MOVED in) and only BORROWS the config,
22
/// so one `Config` serves every job without a single clone.
23
fn process(job: Job, config: &Config) -> String {
24
    let _ = &config.endpoints; // (would be used to dispatch in real code)
25
    format!(
26
        "[{}] job {} -> {} (retries={})",
27
        config.service_name, job.id.0, job.payload, config.max_retries
28
    )
29
}
30

31
fn main() {
32
    let config = Config {
33
        service_name: String::from("ingest"),
34
        max_retries: 3,
35
        endpoints: vec![String::from("https://a"), String::from("https://b")],
36
    };
37

38
    let jobs = vec![
39
        Job { id: JobId(1), payload: String::from("resize-image") },
40
        Job { id: JobId(2), payload: String::from("send-email") },
41
    ];
42

43
    let mut results: HashMap<JobId, String> = HashMap::new();
44
    for job in jobs {
45
        let id = job.id; // JobId is Copy: this does NOT consume `job`
46
        // `job` is moved into `process`; `&config` is only borrowed.
47
        let summary = process(job, &config);
48
        results.insert(id, summary);
49
    }
50

51
    // `config` is still fully usable — it was only ever borrowed.
52
    println!("service still available: {}", config.service_name);
53
    let mut ids: Vec<_> = results.keys().copied().collect();
54
    ids.sort_by_key(|j| j.0);
55
    for id in ids {
56
        println!("{}", results[&id]);
57
    }
58
}

This compiles and prints:

1
service still available: ingest
2
[ingest] job 1 -> resize-image (retries=3)
3
[ingest] job 2 -> send-email (retries=3)

The key design wins, all enforced at compile time: JobId being Copy lets us grab job.id for the map key without consuming job; the &config borrow means the single config object is reused for every iteration with zero allocations; and each Job is moved into process and dropped at the end of that call, so memory is reclaimed deterministically with no GC pauses.

Exercises

Exercise 1: Clone to keep two owners

Difficulty: Easy

Objective: Recognize a move and fix it by cloning when two independent owners are genuinely required.

Instructions: The snippet below does not compile because a is moved into b and then used again. Make it compile without changing the fact that both a and b must be usable afterward and must hold equal contents.

1
fn main() {
2
    let a = String::from("data");
3
    let b = a;            // TODO: a gets used below — make this work
4
    println!("{a} {b}");
5
    assert_eq!(a, b);
6
}

Solution

1
fn main() {
2
    let a = String::from("data");
3
    let b = a.clone(); // explicit deep copy: now there are two owners
4
    println!("{a} {b}");
5
    assert_eq!(a, b);
6
    println!("ex1 ok");
7
}

a.clone() allocates a second heap buffer with the same bytes, so a and b are independent owners. (If you only needed to read a through b, let b = &a; would have avoided the allocation entirely — but the exercise requires two owners.)

Exercise 2: Make a type `Copy`

Difficulty: Medium

Objective: Derive Copy on a small value type so it can be used multiple times without moving.

Instructions: Define a Meters(f64) newtype and an add(a: Meters, b: Meters) -> Meters function. Then call add(d, d) using the same variable d twice and also read d afterward. This is only possible if Meters is Copy — add the right derive.

1
struct Meters(f64); // TODO: derive what you need
2

3
fn add(a: Meters, b: Meters) -> Meters {
4
    // TODO
5
    todo!()
6
}
7

8
fn main() {
9
    let d = Meters(3.0);
10
    let total = add(d, d); // d used twice
11
    assert_eq!(total.0, 6.0);
12
    assert_eq!(d.0, 3.0); // d still usable
13
    println!("ok");
14
}

Solution

1
#[derive(Debug, Clone, Copy, PartialEq)]
2
struct Meters(f64);
3

4
fn add(a: Meters, b: Meters) -> Meters {
5
    Meters(a.0 + b.0)
6
}
7

8
fn main() {
9
    let d = Meters(3.0);
10
    let total = add(d, d); // `d` is COPIED into each argument, not moved
11
    assert_eq!(total, Meters(6.0));
12
    assert_eq!(d, Meters(3.0)); // still usable
13
    println!("ok");
14
}

Because f64 is Copy, a Meters wrapping a single f64 can derive Copy too. Copy requires Clone as a supertrait, so you must derive both. Now passing d twice copies it twice instead of moving it.

Exercise 3: Borrow, then own only what you keep

Difficulty: Medium–Hard

Objective: Take borrowed input, clone only the pieces you decide to keep, and return owned data — the common “build an owned result from borrowed inputs” pattern.

Instructions: Implement collect_unique(items: &[&str]) -> Vec<String> that returns the input strings in first-seen order with duplicates removed. The parameter is borrowed (the function does not own the strings), so you must turn each kept &str into an owned String. collect_unique(&["a", "b", "a", "c", "b"]) must return vec!["a", "b", "c"] (as Strings).

1
fn collect_unique(items: &[&str]) -> Vec<String> {
2
    // TODO: keep first occurrences, return owned Strings
3
    todo!()
4
}
5

6
fn main() {
7
    let result = collect_unique(&["a", "b", "a", "c", "b"]);
8
    assert_eq!(result, vec!["a".to_string(), "b".to_string(), "c".to_string()]);
9
    println!("ok");
10
}

Solution

1
fn collect_unique(items: &[&str]) -> Vec<String> {
2
    let mut out: Vec<String> = Vec::new();
3
    for &item in items {
4
        let owned = item.to_string(); // clone the borrowed &str into an owned String
5
        if !out.contains(&owned) {
6
            out.push(owned); // moved into the Vec; `out` now owns it
7
        }
8
    }
9
    out
10
}
11

12
fn main() {
13
    let result = collect_unique(&["a", "b", "a", "c", "b"]);
14
    assert_eq!(result, vec!["a".to_string(), "b".to_string(), "c".to_string()]);
15
    println!("ok");
16
}

The slice &[&str] is borrowed, so the original strings stay owned by the caller. item.to_string() allocates an owned String (a kind of clone from a borrowed &str), which is then moved into out. The function returns the owned Vec<String> by value — ownership transfers to the caller, no borrow-checker gymnastics required.

Move, Copy, and Clone

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

Move: the default for owned, heap-backed values

Copy: opting out of move for cheap stack values

Clone: explicit, deep, possibly expensive

Moving into functions (and getting ownership back)

Partial moves out of a struct

Key Differences

Common Pitfalls

Pitfall 1: Using a value after it was moved

Pitfall 2: Moving a value into a function, then using it again

Pitfall 3: Deriving `Copy` on a type that owns heap data

Pitfall 4: Reaching for the whole struct after a partial move

Pitfall 5: “Cloning” to silence the borrow checker

Best Practices

Real-World Example

Further Reading

Official Documentation

Exercises

Exercise 1: Clone to keep two owners

Exercise 2: Make a type `Copy`

Exercise 3: Borrow, then own only what you keep

Move, Copy, and Clone

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

Move: the default for owned, heap-backed values

Copy: opting out of move for cheap stack values

Clone: explicit, deep, possibly expensive

Moving into functions (and getting ownership back)

Partial moves out of a struct

Key Differences

Common Pitfalls

Pitfall 1: Using a value after it was moved

Pitfall 2: Moving a value into a function, then using it again

Pitfall 3: Deriving Copy on a type that owns heap data

Pitfall 4: Reaching for the whole struct after a partial move

Pitfall 5: “Cloning” to silence the borrow checker

Best Practices

Real-World Example

Further Reading

Official Documentation

Related Sections in This Guide

Exercises

Exercise 1: Clone to keep two owners

Exercise 2: Make a type Copy

Exercise 3: Borrow, then own only what you keep

Pitfall 3: Deriving `Copy` on a type that owns heap data

Exercise 2: Make a type `Copy`