Rust Ownership Explained: Why Some Values Move and Others Copy

itzlg | cyborg — Mon, 01 Sep 2025 21:17:40 +0000

When we assign a value to a new variable in Rust, the value is usually moved. But here’s the catch ,this depends on the type of the value.

Rust plays a little trick when you assign values: some get copied, others get moved, depending on their type.

Primitive Types (Copy)

For primitive types like integers, booleans, and floats, the value is not moved. Instead, it is copied.

Why?

They implement the Copy trait.
They are stored on the stack.
They have a fixed size known at compile time.
Copying them is extremely cheap and efficient.

👉 Example:

let x = 5;
let y = x; // y gets a copy, x is still valid
println!("x = {}, y = {}", x, y);

Both x and y remain valid because i32 or u32 implements Copy.

Complex Types (Move)

For types like String, Vec, and most custom structs, Rust does not copy the value by default, it moves it.

Why?

They are stored in the heap.
Their size is not fixed at compile time.
Copying them would require duplicating potentially large amounts of data, which is expensive.

👉 Example:

let s1 = String::from("hello");
let s2 = s1; // ownership moved
// println!("{}", s1); // ❌ Error: s1 is no longer valid

How to Avoid Moving

Sometimes, you don’t want to lose access to the original variable . Rust gives you two options:

Clone it:

let s1 = String::from("hello");
let s2 = s1.clone();
println!("s1 = {}, s2 = {}", s1, s2);

This creates a deep copy of the value (including nested values if present) and allocates new memory in the heap which is safe but potentially expensive
Note: (If it’s not a String, e.g., a struct, you can still call .clone() as long as the type implements the Clone trait.)

Borrow (use references):

let s1 = String::from("hello");
let s2 = &s1; // borrow instead of move
println!("s1 = {}, s2 = {}", s1, s2);

Copy vs Clone

Copy:

Shallow copy
For small, fixed-size types stored on the stack
Very cheap

Clone:

Deep copy
For complex types stored on the heap
Allocates new memory, can be expensive

Rust’s ownership model might feel strict at first, but once you understand the difference between Move, Copy, and Clone, things start to click. The rules are there to help you write safe and efficient code without worrying about memory bugs.

If you found this helpful, please leave a comment or reaction 👏 it really motivates me to share more Rust content.

You can also connect with me on X (Twitter): @melovegupta 🚀

How the JavaScript code works behind the scene ?

itzlg | cyborg — Thu, 11 May 2023 19:40:40 +0000

I have seen a lot of people who know frontend but don't know very well how JavaScript works. In this post, I will share my learning so that if anyone asks you about this topic, or if an interviewer asks you a question related to this topic, you will not be confused. Let's start! :

When we run our JavaScript code , at that time JavaScript engine execute that code in two phases that is
1-creation phase
2-execution phase

In creation phase , memory is allocated to all the variables and functions , for variables a special value Undefined is assigned to all variables and for function entire code gets copied in memory,
in execution phase js code is executed line by line and in this phase undefined value of variable is replaced by actual value that we were assigning in that variables

for ex:- let a=20

so firstly in creation phase memory is allocated to variable a with undefined value
after that in execution phase value 20 is assigned to a.

So here very interesting topic comes in picture that is hoisting .
In Hositing you can use a variable or function before it is declared, and JavaScript will still be able to find it.

However, variables created using the 'let' and 'const' keywords are also present in the TDZ (temporal dead zone), so we cannot access those variables before defining or declaring them. Attempting to do so will result in an error.

 console.log(a);
let a=20;
output :you can not access it before declaring

However, if we use the 'var' keyword with variables, the variables that are created using the 'var' keyword do not exist in the TDZ. Therefore, accessing them before declaring or defining them will not result in an error, but will instead show 'undefined'.

console.log(a);
var a=20;
ouput: undefined

But It's generally a good practice to declare all variables and functions at the top of their respective scopes
I hope you will get useful information and I welcome your suggestion 😀

Forem: itzlg | cyborg