Rust vs TypeScript: when to use each

Choosing a programming language looks like a technical decision, and it is also a hiring, maintenance and risk decision that an owner or finance lead lives with for years. Rust and TypeScript sit at opposite ends of that trade. One is built for fast, safe change in business software, and the other for squeezing predictable performance out of the machine.

Rust vs TypeScript: which should you use?

Use TypeScript by default for web applications, APIs, internal tools, portals and most business software. Use Rust for a defined problem that TypeScript handles poorly: heavy computation, tight latency targets, embedded and edge devices, or code that parses untrusted input where memory safety matters. Many teams use both, with Rust under or beside a TypeScript application.

What does each language guarantee?

TypeScript: checks before runtime, none during

TypeScript adds types to JavaScript and checks them before the code runs. Then it throws them away. The official handbook states it directly: type annotations are completely erased, and "type annotations never change the runtime behavior of your program." The consequence for a business is specific. TypeScript catches a misspelled field or a wrong argument at build time, and it does not verify that the JSON an API returns or a form submits matches the declared type. Data crossing a boundary still needs validation at runtime.

Rust: ownership as a compile-time contract

Rust manages memory through ownership. The Rust book gives three rules: each value has an owner, there can be only one owner at a time, and the value is dropped when the owner goes out of scope. The compiler checks the rules, and if any are violated the program will not compile. The book adds that none of the features of ownership slow the program while it runs.

This prevents whole classes of bug. The book describes the double free, where two variables try to free the same memory, as a memory safety bug that can lead to memory corruption and security vulnerabilities. Rust also turns data races into compile-time errors rather than runtime surprises, though deadlocks and logic races remain possible. Rust has an unsafe keyword that lets a programmer opt out of these checks in marked blocks, so the guarantee holds for safe code, provided the unsafe code it relies on, including in dependencies, is correct.

What do the survey numbers say about hiring and developer sentiment?

In the 2026 Stack Overflow Developer Survey, 43.8% of 14,099 respondents reported using TypeScript, against 18.0% for Rust. Rust drew more admiration: 67.4% of people who had used it wanted to keep using it, against 53.0% for TypeScript. The share who wanted to use each next year was close, at 26.3% for Rust and 27.5% for TypeScript. Stack Overflow's own write-up says Rust moved up to the 12th most used language.

Read these carefully. Usage is a rough proxy for the size of the hiring pool and is not labor market data. Admiration measures how people who already use Rust feel, and does not say how many are available to hire in your city or time zone.

When does Rust earn its cost?

Rust has earned its place where a measured problem met a language that removes it. Two first-party engineering posts show the pattern.

Discord, a latency problem. In 2020, Discord described a Read States service, queried on every connect, message send and message read, that showed latency spikes about every two minutes. It traced them to Go's garbage collector scanning a large cache. The first Rust version matched Go's latency with no spikes, and after optimization beat Go on latency, CPU and memory, which let the team raise the cache capacity to 8 million Read States. The post shows results in charts and gives no exact percentages.

Cloudflare, a safety and efficiency problem. In 2022, Cloudflare explained why it built its Pingora proxy in Rust to replace NGINX, which it noted is written in C, which is not memory safe by design. Pingora serves over 1 trillion requests a day, and Cloudflare reported about 70% less CPU and 67% less memory than the old service under the same traffic. For one major customer, connection reuse rose from 87.1% to 99.92%.

Both were internet-scale systems with a problem someone had measured. Treat them as evidence of where Rust helps, and not as a forecast for a business application that handles thousands of requests a day.

Why is the TypeScript compiler being ported to Go and not Rust?

The TypeScript team's own project is a useful counterpoint. In March 2025, Microsoft announced a native port of the compiler to cut build times by about 10x. On the VS Code codebase of roughly 1.5 million lines, the type-check fell from 77.8 seconds to 7.5 seconds in its measurements. InfoQ reports that TypeScript 7.0 shipped as the first stable version on the native compiler, with full builds typically 8x to 12x faster.

The team chose Go, and the reason was porting cost. Ryan Cavanaugh wrote that the most important aspect was keeping the new codebase as compatible as possible with the old one, because both would be maintained for a long time. Go's idioms strongly resemble the existing patterns, the work was a port that keeps existing behavior and not a rewrite, and the downsides of garbage collection were not salient for a compiler. A language that demands rethinking memory management suits a ground-up rewrite better.

Two lessons carry over. The speedup came from leaving JavaScript for native code and using several cores, which Rust and Go both offer. And language choice followed the shape of the existing code and the team, which is the same logic you should apply.

Can you use Rust and TypeScript together?

Yes, and many teams do. TypeScript stays the language of the application, and Rust appears in three places.

• Rust-written tooling. SWC is a Rust-based compiler platform used by Next.js, Parcel and Deno, and it claims to be 20x faster than Babel on a single thread. Biome is a Rust formatter and linter that claims about 35x faster formatting than Prettier on its own benchmark. These are vendor claims, and the practical point is that your TypeScript project may already run Rust in its build.
• Native Node.js addons. NAPI-RS builds pre-compiled Node.js addons in Rust, so a TypeScript service can call a fast Rust function directly.
• WebAssembly. MDN describes compiling Rust to WebAssembly with wasm-pack and wasm-bindgen, and says that as far as the JavaScript code can tell, the result is just a normal module.

The pattern fits Node.js's design. Node runs JavaScript on a single thread by default, and long-running callbacks delay everything queued behind them. Moving one heavy function into Rust keeps the rest of the system in the language your team knows.

What does it cost a 20 to 200 person company to adopt Rust?

The cost is mostly people, and it shows up in four places.

• Hiring. The pool is smaller, as the survey numbers suggest, and a senior Rust engineer is likely a harder search than a senior TypeScript engineer.
• Learning. Ownership is a new mental model for JavaScript developers, so expect the first project to run slower while people learn it.
• Build time. Compile time is a standing complaint. Rust's 2025 survey lists resource usage, including slow compiles, among its top problems, and its compiler performance survey found that around 45% of respondents who no longer use Rust cited long compile times among their reasons.
• Maintenance. A second toolchain to patch and a service only one person can read are both ongoing costs. These belong in the same conversation as what drives the cost of custom software.

Illustrative example: Consider a 70-person company whose eight-person engineering team writes everything in TypeScript. A report service that parses large supplier files keeps blocking its Node.js process for minutes. The cheapest fix is to move the parsing to a queue and a separate worker, which the team can do this week in a language it knows. If profiling then shows that one parsing function dominates, that function could become a Rust module behind a small interface. Rewriting the whole service in Rust would make the team dependent on whichever one or two engineers learned the language, and that is the risk to price before starting.

How should you decide?

Work through these steps in order.

1. Default to TypeScript for web applications, APIs, internal tools and integrations.
2. Measure first. Profile the real system to find where the time or memory goes.
3. Try the cheaper fixes. Caching, a database index, a queue or a separate worker process often remove the problem.
4. Isolate any remaining hot path and consider writing only that part in Rust, behind a narrow interface.
5. Choose a Rust service when tail latency, memory footprint at scale, embedded targets or the safe parsing of untrusted input is the actual requirement.
6. Confirm two people can maintain it before it ships.

These questions sit alongside the others in our list of system design questions, which covers the wider choices around data, queues and scale.

How Kastling approaches language choices

Kastling would start with the work the software has to do and the team that will maintain it, and pick the technology after that. For web applications, internal tools and integrations that would usually mean TypeScript, with Rust considered for a specific measured need, and hosting on AWS or Azure. Success measures are agreed before the build, development is tested against real business scenarios, and a named person stays in control of consequential decisions. This sits within Custom Solutions.