TypeScript to Rust: The Complete Transition Guide

My name is Max and I'm the founder of Rustify.

I've been writing Rust professionally for 2 years and I've helped dozens of engineers make the switch to Rust professionally.

If you want to go further, here's how I can help:

• Fullstack Bootcamp: structured program with real projects, async support, and private community access.
• Blockchain Bootcamp: structured program with real projects, async support, and private community access.
• 1:1 Mentorship: personalized sessions to get you hired faster, with projects tailored to you and mock interviews.

And if you want more Rust content, I post regularly on my YouTube channel:

Send me the PDF →

No spam. Unsubscribe any time.

Get it

If you're reading this, you already know the ceiling.

"TypeScript developer." It's on your LinkedIn. It's how recruiters find you. And it's also the reason you don't show up for a category of roles you know you could do.

TypeScript developers with your background are moving into those roles right now. Shipping production Rust. Working on infrastructure, systems, the kind of code that doesn't have to explain itself in an interview.

Most engineers read a guide like this, bookmark it, and go back to their Node ticket. Do you want to stay one of them?

If you're reading this, probably not.

Then this guide is for you.

This guide maps what you already know to how Rust thinks. Your type instincts, async habits, and API design experience transfer. The one thing you're actually adding is ownership.

Part 1 — Your Head Start

What transfers directly from TypeScript. Read this first. It'll reset your expectations for how hard this actually is.

The Big Picture: You're Not Starting Over

Here's what most people get wrong about this transition: they treat Rust like a completely different world. It's not. It's more like TypeScript's stricter, faster, more opinionated cousin who went to study compilers for three years and came back with strong opinions about memory.

For TypeScript engineers, the move to Rust is usually:

• keep the type discipline
• keep the async intuition
• keep the backend design instincts
• add ownership, borrowing, and stronger guarantees

That's why the transition feels very different from "learn your first systems language."

TYPESCRIPT -> RUST
│
├── WHAT ALREADY TRANSFERS
│   ├── types + generics
│   ├── async / await syntax
│   ├── API design instincts
│   ├── Result / Option thinking (if you use fp-ts or similar)
│   └── trait = interface (mostly)
│
├── WHAT IS GENUINELY NEW
│   ├── ownership — values have one owner
│   ├── borrowing — temporary access without ownership
│   ├── lifetimes — how long borrows are valid
│   ├── no garbage collector — memory is deterministic
│   └── no runtime exceptions — errors are values, always
│
└── END STATE
    ├── ship a real Rust API (Axum + SQLx + Tokio)
    ├── speak credibly with hiring managers
    └── move from "web dev" bucket to "serious backend" bucket

The Type System: What Maps Directly

This is where TypeScript developers have a real head start, and usually the first thing that surprises them about Rust. You don't need to re-learn types. You need to re-learn how strict the compiler is about enforcing them.

Most of the Rust type system has a direct TypeScript equivalent:

The biggest upgrade Rust gives you over TypeScript: enums with data. TypeScript has discriminated unions, which are clever but verbose. Rust enums are first-class citizens of the language, and pattern matching on them is exhaustive. The compiler tells you when you've missed a case.

// TypeScript: union types — workable, but wordy
type Shape =
  | { kind: "circle"; radius: number }
  | { kind: "rect"; width: number; height: number }
 
// Rust: enum with data — clean, exhaustively checked at compile time
enum Shape {
    Circle { radius: f64 },
    Rect { width: f64, height: f64 },
}

Once you've used Rust enums for a month you'll miss them every time you go back to TypeScript. That's usually the moment my clients stop thinking of Rust as a side project.

You already have the foundation. Here's what makes Rust different from everything you've built on top of it.

Part 2 — What You're Actually Adding

The mental models that don't exist in TypeScript. This is the dense part. Take your time here. Everything else builds on it.

Ownership: The One Thing That Is Actually New

This is where most TypeScript developers slow down. Not because it's impossibly hard. TypeScript has no equivalent. You can't Google "ownership but in TypeScript." There's nothing to map it to. You have to build the model from scratch.

Here's the model in one sentence:

Every value in Rust has exactly one owner. When the owner goes out of scope, the value is dropped. Freed from memory. No garbage collector needed.

In TypeScript, your runtime handles this silently in the background. In Rust, you think about it explicitly, and the compiler enforces it before your code ever runs.

Move semantics: the shift that takes the longest to internalize

In TypeScript, passing a value to a function passes a reference. The original is still accessible.

In Rust, passing a value to a function moves it. The original is gone. Ownership transferred.

let name = String::from("Alice");
let greeting = make_greeting(name); // name is moved here
 
println!("{}", name); // ❌ compiler error: name was moved

This error feels wrong the first time. You're not misusing memory. You're not doing anything dangerous. But the compiler is teaching you something: ownership of name left this scope. If two places could use name at the same time, bugs happen. Rust eliminates that class of bug at compile time.

The solutions:

1. Borrow instead of move: pass &name to let the function look without taking ownership
2. Clone: explicitly copy the value with .clone() if you need two independent copies
3. Return ownership: the function gives the value back in its return

// Borrow: function reads but doesn't own
fn print_name(name: &str) {
    println!("{}", name);
}
 
let name = String::from("Alice");
print_name(&name); // borrow — name still here
println!("{}", name); // ✅ works fine

Once ownership lands, usually around week two, it changes how you think about data flow. You stop writing defensive null checks. You stop adding "just in case" clones. You stop having production surprises around shared mutable state.

Most of my clients describe this as the moment Rust stops feeling like a compiler you are fighting and starts feeling like a type system that has your back. That shift is what makes the switch feel permanent.

The key insight: most borrow checker errors are pointing at a real design problem. The compiler is not being pedantic. It found the bug you were about to ship.

Error Handling: Say Goodbye to try/catch

TypeScript uses exceptions. Rust does not. This is not a limitation. It's one of the best things about the language.

In Rust, every function that can fail returns a Result<T, E>. Errors are regular values. There's no throw, no uncaught exception, no mysterious production crash because someone forgot a try/catch three layers up the call stack.

If you've ever used fp-ts or neverthrow in TypeScript you already know the mental model. The difference is that in Rust, this isn't a library convention. It's enforced by the language. Every caller must handle errors. You cannot accidentally swallow them.

// TypeScript: can throw — caller might not know or care
function readFile(path: string): string { ... }
 
// Rust: explicit contract — caller must handle the error case
fn read_file(path: &str) -> Result<String, io::Error> { ... }

The ? operator is the ergonomic shortcut. It propagates errors up automatically, like a try/catch that's honest about what it's doing.

fn process() -> Result<String, io::Error> {
    let content = read_file("data.txt")?; // if error, return early with it
    let parsed = parse(content)?;         // same here
    Ok(parsed)
}

The mental model to adopt: errors are a second return value, not an emergency exit. Write your code that way from day one and everything else about Rust error handling falls into place. Six months from now, this is the section you'll be explaining to the TypeScript developer on your team.

Async Rust: Familiar Syntax, Stricter Rules

The syntax is almost identical to TypeScript. The semantics are stricter in ways that matter.

// TypeScript
async function fetchUser(id: number): Promise<User> {
    const user = await db.find(id);
    return user;
}
 
// Rust
async fn fetch_user(id: i64) -> Result<User, DbError> {
    let user = db.find(id).await?;
    Ok(user)
}

Looks the same. Under the hood, three things are different:

1. You choose your executor. Rust has no built-in async runtime. There's no Node.js event loop baked in. You pick one. Almost always Tokio for backend work. Add #[tokio::main] to your main function and you're done. It's a one-time setup and then it disappears.

2. Futures are lazy. A Rust Future does nothing until you .await it. A JavaScript Promise starts running the moment you create it. This means you can construct complex async logic and compose it before any of it executes, which is powerful once you understand it, and confusing until you do.

3. Send bounds on spawned tasks. When you spawn a task with tokio::spawn, Rust requires the future to be Send, meaning it can safely move between threads. If you hold a Mutex guard across an .await point, the compiler rejects it. This is the error that would have been a race condition in production Node. Rust makes it a compile error instead.

Expect one to two weeks of confusion specifically around Send bounds and lifetime errors in async closures. Push through it. These are bugs that used to surface in production on a Saturday. Now they surface in your terminal on a Tuesday afternoon.

Traits, impl Trait, and dyn Trait

TypeScript interface defines the shape of an object (structural typing). Rust trait defines behavior a type must implement. The difference sounds subtle, but it changes a lot.

The key thing TypeScript interfaces can't do: you can implement a trait on a type you don't own, after the fact.

trait Summarize {
    fn summary(&self) -> String;
}
 
// Implement on a type from the standard library — no modification needed
impl Summarize for Vec<String> {
    fn summary(&self) -> String {
        format!("{} items", self.len())
    }
}

Common traits every Rust backend developer uses daily:

• Clone: explicit copying
• Debug: print a value for debugging ({:?})
• Display: human-readable string output ({})
• From / Into: type conversions
• Serialize / Deserialize (serde): JSON, TOML, etc.
• Error: define custom error types

Most of these can be automatically derived. You'll write #[derive(Debug, Clone, Serialize, Deserialize)] on almost every struct you create. The compiler writes the boilerplate. You don't.

impl Trait vs dyn Trait

Once you're using traits, you'll encounter this choice. In TypeScript you don't think about it (structural typing just works). In Rust, two dispatch mechanisms exist and they compile differently.

impl Trait: resolved at compile time (static dispatch). The compiler generates a version of the function for each concrete type. Zero runtime overhead.

fn process(input: impl Display) { println!("{}", input); }

dyn Trait: resolved at runtime (dynamic dispatch). Uses a vtable. Tiny overhead, but lets you store different concrete types in the same place.

// Only possible with dyn — different types in one Vec
let handlers: Vec<Box<dyn Handler>> = vec![HandlerA, HandlerB, HandlerC];

Decision rule: function parameter with known type → impl Trait. Storing mixed types in a collection or field → Box<dyn Trait>.

String vs &str: The First Wall Every TS Dev Hits

In TypeScript, string is string. You pass it around, concatenate it, forget about it.

In Rust, there are two string types, and they confuse every TypeScript developer on day one. Sometimes day two. Occasionally day five, if things go well.

String: owned, heap-allocated, growable. You have full control. You can modify it, append to it, move it.

&str: a borrowed view into a string. No allocation. Read-only. Think of it like a pointer into existing string data.

The rule that covers 90% of cases:

• Function parameter that only reads a string: use &str
• Function that needs to store, build, or return a string: use String

// ✅ Just reading — borrow a view, no allocation needed
fn greet(name: &str) {
    println!("Hello, {}!", name);
}
 
// ✅ Building something — return owned String
fn build_greeting(name: &str) -> String {
    format!("Hello, {}!", name)
}

Rust coerces String to &str automatically. So you can always pass a String where &str is expected — the other direction requires an explicit conversion.

Conversions to know:

• String → &str: just &my_string
• &str → String: .to_string() or String::from("...")

Part 3 — Shipping a Real Axum API

Theory is fine. This is the part that gets you to production.

This is where your TypeScript background stops being a comparison point and starts being an advantage.

The Crates You'll Actually Use

The Rust crate ecosystem for backend development is smaller than npm — but for backend APIs, everything you need exists, is actively maintained, and compiles to nothing. No 300MB node_modules. No transitive dependency that last committed in 2019.

Start with these. Learn them properly. Resist the urge to add more until you need them.

Axum vs Express: The API You Already Know, But Safer

TypeScript developers coming from Express or Fastify will find Axum familiar in structure and better in almost every other way. No more req.body as MyType and hoping for the best.

Defining routes:

// Express
app.get('/users/:id', async (req, res) => {
    const user = await db.findUser(req.params.id) // string, hope it's a number
    res.json(user)
})

// Axum — path param is typed, extracted, validated before your code runs
async fn get_user(Path(id): Path<i64>, State(db): State<Db>) -> impl IntoResponse {
    let user = db.find_user(id).await?;
    Json(user)
}
 
let app = Router::new()
    .route("/users/:id", get(get_user))
    .with_state(db);

The key shift: parameters are typed and extracted at the function signature level. No req.params, no manual parsing, no parseInt and crossed fingers. If the path param can't parse to i64, Axum rejects the request before your handler even runs.

Middleware:

Express uses app.use(). Axum uses Tower layers. Composable, type-safe.

let app = Router::new()
    .route("/", get(handler))
    .layer(TraceLayer::new_for_http())
    .layer(CorsLayer::permissive())
    .layer(CompressionLayer::new());

Error responses:

In Express you'd scatter res.status(400).json(...) through every handler. In Axum, implement IntoResponse on your error type once, then use ? everywhere.

impl IntoResponse for AppError {
    fn into_response(self) -> Response {
        let status = match self {
            AppError::NotFound => StatusCode::NOT_FOUND,
            AppError::Unauthorized => StatusCode::UNAUTHORIZED,
            _ => StatusCode::INTERNAL_SERVER_ERROR,
        };
        (status, Json(json!({ "error": self.to_string() }))).into_response()
    }
}

One implementation. Consistent error responses across every handler. Define this on day one. The developers who ship think this way from the start.

Project Structure: What a Real Axum API Looks Like

Rust doesn't enforce a folder structure. Without a convention, beginners create chaos. Here's the structure that works in real production Axum APIs.

my-api/
├── Cargo.toml
├── .env
├── migrations/
│   └── 001_init.sql
└── src/
    ├── main.rs          # entry point, router setup, DB pool init
    ├── config.rs        # env vars, app config struct
    ├── errors.rs        # AppError type + IntoResponse impl ← do this first
    ├── db.rs            # DB connection pool setup
    │
    ├── routes/          # one file per resource
    │   ├── mod.rs
    │   ├── users.rs
    │   └── auth.rs
    │
    ├── models/          # structs that map to DB rows
    │   ├── mod.rs
    │   └── user.rs      # User, CreateUser, UpdateUser
    │
    └── services/        # business logic, DB queries
        ├── mod.rs
        └── user_service.rs

Create errors.rs on day one. Define your AppError type, implement IntoResponse, have every handler return Result<T, AppError>. Retrofitting proper error handling into an existing Axum codebase is nobody's idea of a good time.

Cargo vs npm: The Commands You Need

Install cargo-watch early: cargo install cargo-watch. Run cargo clippy constantly. It's the code reviewer you always wanted but couldn't afford.

Iterators: Where Rust Genuinely Beats TypeScript

TypeScript has .map(), .filter(), .reduce(). They're fine. Rust has the same, and they cost nothing at runtime.

In JavaScript, each chained method allocates a new intermediate array. In Rust, the entire chain is lazy: nothing executes until you call .collect(). The compiler fuses everything into a single loop with no intermediate allocations. Functional-style code with loop-level performance.

// Looks like functional JS. Compiles to a single tight loop.
let result: Vec<i32> = (1..=100)
    .filter(|x| x % 2 == 0)
    .map(|x| x * x)
    .take(5)
    .collect();
// → [4, 16, 36, 64, 100]

Always end your chain with .collect(). Rust won't materialize the result implicitly. That's the point.

The Borrow Checker: Learning to Read the Errors

Four errors cover 80% of what beginners hit. Here's what they mean and how to fix each.

cannot move out of ... because it is borrowed

You're trying to transfer ownership of something that's currently being borrowed. Let the borrow end first.

let s = String::from("hello");
let r = &s;
let moved = s;       // ❌ r is still borrowing s
println!("{}", r);

cannot borrow as mutable because it is also borrowed as immutable

Holding a read reference and trying to get a write reference simultaneously. Rust doesn't allow it. This is what prevents data races.

let mut v = vec![1, 2, 3];
let first = &v[0];
v.push(4);              // ❌ mutable borrow while first is alive
println!("{}", first);

Fix: finish using first before mutating v.

does not live long enough

Returning a reference to a local value. The local gets dropped at the end of the function — the reference would point to nothing.

fn get_greeting() -> &str {
    let s = String::from("hi");
    &s  // ❌ s is dropped here
}

Fix: return an owned String instead.

cannot use ... after move

Passed a value into a function and tried to use it again.

let name = String::from("Alice");
log(name);
println!("{}", name); // ❌ name was moved into log()

Fix: borrow instead (log(&name)) or clone if you genuinely need two copies.

The pattern to internalize: the borrow checker is a scope and aliasing checker. Most errors resolve by adjusting order of operations or switching a move to a borrow. .clone() is the honest escape hatch when you're stuck. Just don't reach for it before understanding why.

One more thing worth saying out loud: every error the borrow checker shows you is a real bug. Not a style preference. Not the compiler being pedantic. A bug that would have made it to production in any other language.

Part 4 — The Bigger Picture

Ecosystem, career, and what to do next.

Full-Stack Rust Is a Real Option Now

One thing that surprises TypeScript developers: you don't have to stop at the backend.

With Leptos (full-stack Rust framework) and Rust UI, a component library built like shadcn/ui for Rust, you can build complete cross-platform applications entirely in Rust. Same language, same types, frontend and backend. No TypeScript layer. No context switching.

Rust UI is open source and actively maintained. If you want to get hands-on with real Rust code faster than building everything from scratch, or show companies you're already contributing to the Rust ecosystem, not just learning it, contributing to Rust UI is a practical way to do both.

"I contributed to an open-source Rust component library" is a much better conversation starter with a hiring manager than "I finished the Rust Book."

Explore Rust UI →

The Market Argument

There are more Rust roles than qualified Rust developers. That gap is real, it's been real for three years, and it's not closing fast — because Rust is genuinely harder to learn and most engineers don't bother.

Companies that need Rust are not hiring junior engineers to figure it out. They want engineers who already have backend instincts and can learn the language. TypeScript developers already have the backend instincts.

You don't reset your career. You add the rare skill on top of the existing foundation.

Developers I've worked with went from their first ownership error to shipping complex, cross-platform Rust systems in production. The gap between reading and building is exactly what the program is designed to close. The bar is lower than it looks from the outside, because most engineers don't try. If you want to build that profile with real projects and structured feedback, that's what the mentorship is for.

The roles that pay a premium for Rust:

• fintech and trading (latency-sensitive, correctness-critical)
• infrastructure and DevTools (CLI tools, compilers, build systems)
• B2B SaaS companies rewriting Python/Node services that can't scale
• web3 (Solana, etc.)

Most engineers in these companies are not "pure Rust developers." They're backend engineers who also write Rust. That's the profile you're building.

Why Most TypeScript Developers Never Finish the Switch

These are not mistakes that happen to bad developers. They happen to developers who never had someone catch them early.

Cloning everything to avoid borrow checker errors

The compiler is angry, .clone() makes it happy, you move on. This works but you've learned nothing. When you clone to silence an error, stop and ask: does this function actually need to own the value, or should it borrow? Nine times out of ten, borrow is the right answer and clone is a band-aid.

Spreading .unwrap() everywhere like console.log statements

.unwrap() panics on error. Fine in a script you run once. Not fine in a production API. Learn ? in your first week and use it. When your API 500s in production because of an .unwrap() you forgot about, this mistake gets expensive fast. I have seen this take down more than a few production services, including ones belonging to engineers who were confident they understood error handling.

Carrying over TypeScript's defensive runtime checks

In TypeScript you check if (user !== null) everywhere because null sneaks in from anywhere. In Rust, Option<User> forces you to handle the absent case at the type level — before the function runs, not after. Express the constraint in the type. Let the compiler enforce it.

Fighting the borrow checker instead of listening to it

The borrow checker rejected your code. Your first instinct is to add Rc<RefCell<T>> or Arc<Mutex<T>> to make it shut up. Stop. Read the error. It's almost always telling you that two parts of your code are trying to use the same data in a way that would cause a problem. Restructure the data flow first.

Skipping ownership (chapter 4) to get to "useful" things faster

Every TypeScript developer who skips ownership to get to async Rust regrets it. You hit the same wall every time, just later and with more momentum lost. Spend the week. The rest of the book, and the rest of your Rust career, depends on it.

The Fastest Path Is Not Self-Teaching

Most TypeScript developers who try to self-teach Rust hit the same wall: they get through the Rust Book, understand ownership conceptually, feel pretty good about it, and then stall completely when they try to build something real.

The Book teaches the language. It doesn't teach you how to ship. That's the gap.

It doesn't teach you how to structure an Axum API, wire up SQLx migrations, handle auth properly, write integration tests, or debug the borrow checker errors that only show up in async code after a deployment.

Every developer I've worked with hit this wall. The ones who got through it had structure and someone to catch the errors before they compounded.

The Rustify Fullstack Bootcamp is 3 months of structured projects — ownership, async, Axum, SQLx, authentication, real deployments — with direct feedback from engineers who've shipped Rust in production. Not recorded videos you watch alone. A program with a path and people who've already solved the problems you'll hit.

If you're serious about making the move:

See the full bootcamp curriculum →

FAQ

I got stuck on the borrow checker for days. Is that a bad sign?

No. Everyone does. Seriously. It's so universal that it's almost a rite of passage. The borrow checker is enforcing a model that TypeScript never asked you to think about. Getting stuck is the learning. It usually lands sometime in the second or third week of actual practice, not passive reading.

Can I use Rust for full-stack development?

Yes. Leptos is a full-stack Rust framework — server-side rendering, client-side reactivity, shared types between frontend and backend, no JavaScript required. If you want end-to-end type safety without a separate TS layer, it's worth exploring. TypeScript experience transfers well because the component model is familiar — minus the undefined is not a function surprises.

Should I learn Go instead? It's easier.

Go is easier to learn. It's also an easier skill to find. The supply of Go developers is growing fast and the language is simpler — which means less differentiation. Rust requires more investment but the supply of qualified engineers is structurally low. Both are legitimate paths. The question is whether you want speed of entry or depth of competitive moat.

Every developer I work with chose the moat. None of them have regretted it.

Can't I just learn from free content?

You can. The Rust Book is genuinely excellent — one of the best language books ever written. The gap isn't information. It's structure, feedback loops, and real project experience. Most engineers who only use free content stop after the Book because there's no project pulling them forward. The Book teaches you the language. Building an API with auth, a database, migrations, and integration tests teaches you how to ship.

How long until I'm actually productive?

For TypeScript developers: 4–6 weeks to ship something real if you're focused. The first two weeks are hardest because ownership is genuinely new. After that, progress compounds fast, because so much of the rest maps directly to what you already know. The borrow checker stops feeling like a wall and starts feeling like a colleague who catches your mistakes before they matter. Four to six weeks. That's the gap between you now and the version of you who introduces himself as a Rust engineer.

Is Node.js good enough? Why bother?

For most CRUD workloads, yes. Node is fine. But when companies hit CPU, memory, or latency ceilings — when "better Node" stops being the answer — they stop looking for senior Node developers and start rewriting. Rust is where those rewrites go. The engineers who can lead that work are rare and well-compensated. That's the bet you're making.

What if I'm not a "systems programmer"?

That used to be a meaningful distinction. Today, many working Rust backend engineers came from Python, TypeScript, and Ruby. You do not need a CS degree, prior C experience, or a deep love of memory allocators. You need enough patience to stay in the compiler errors long enough to understand what they're saying. That's it.

There are two types of TypeScript developers who read a guide like this.

The first one closes it, goes back to their Node ticket, and tells himself he'll get to Rust eventually. Two years from now he's still introducing himself as a TypeScript developer. He watches people around him move into roles he knows he could fill.

The second one decides this is the guide that marks the before and after. He ships something in Rust inside a month. He stops saying "I work in TypeScript" and starts saying "I work in Rust." He applies to roles that would have filtered him out six months ago.

The difference is not skill. It is not time. It is a decision made right now.

Every year in the first category costs real money. Rust backend engineers in Europe earn €90k to €130k. Senior TypeScript developers in the same market earn €60k to €80k. The gap is €30k to €50k per year, compounding silently.

The developer who made the switch looks like this.

When someone asks what stack he uses, he says "Rust" without qualifying it. He doesn't add "I'm coming from TypeScript" as context anymore — because it's no longer the frame.

When he sees a job posting that used to filter him out, he applies. He doesn't wait to feel ready.

When he hits a borrow checker error, he reads it. He doesn't reach for .clone(). He restructures.

When he negotiates, he negotiates for what the role is worth — not what he thinks a "web developer making the transition" deserves.

That version of you is three months of focused work away.

You already know which category you want to be in. If you're still reading, you're probably already in the second one.

You just need someone to help you close the gap faster.

Book a call →

If you want to go from reading this to actually shipping Rust professionally, with real projects, structured feedback, and a faster path through ownership, async, Axum, and SQLx, that's exactly what Rustify is built for:

• Fullstack Bootcamp: structured program with real projects, async support, and private community access.
• Blockchain Bootcamp: structured program with real projects, async support, and private community access.
• 1:1 Mentorship: personalized sessions to get you hired faster, with projects tailored to you and mock interviews.

Send me the PDF →

No spam. Unsubscribe any time.

Get it