What Rust Teaches JavaScript
Ownership, explicit state, and why learning Rust may make you a better JavaScript architect — even if no .rs file ever reaches production. The useful part of Rust is the set of questions its compiler refuses to let you avoid.
Table of Contents
Ownership, explicit state, and why learning Rust may make you a better JavaScript architect — even if no .rs file ever reaches production.
There is an obvious reason for a JavaScript developer to learn Rust: sometimes Rust is the better language.
That answer is correct. It is also not particularly interesting.
The more important reason is that Rust changes how you think about programs written in other languages. After sufficient exposure to Rust, a JavaScript codebase begins to look slightly different. Objects acquire histories. References acquire consequences. A function returning undefined begins to look suspicious. A Promise is no longer synonymous with concurrency. A global cache becomes less obviously convenient. An innocent closure suddenly has a lifetime. And an API that can return five logically distinct outcomes but represents four of them by throwing exceptions begins to feel structurally dishonest.
None of this means JavaScript should imitate Rust syntactically. It should not.
JavaScript has a garbage collector. It is dynamically executed. TypeScript uses structural typing. Node is built around an event loop and asynchronous I/O. Hono deliberately uses Web APIs such as Request, Response, Headers and fetch. Nuxt places Vue, server rendering and Nitro around a remarkably portable JavaScript server architecture. These systems solve different problems from Rust.
The conceptual lessons transfer anyway. In the JavaScript architecture emerging in 2026, they may transfer better than they did five years ago.
Hono describes itself as a framework built on Web Standards rather than Node-specific abstractions, and runs across Node, Bun, Deno, Cloudflare Workers, Fastly, Lambda and other environments. Nuxt 4 similarly builds its server through Nitro into a deployable system capable of targeting Node, serverless and edge runtimes. The runtime is becoming an implementation detail rather than the architectural centre of the application.
That changes what good JavaScript architecture looks like.
And strangely enough, it makes Rust increasingly relevant.
Rust is famous for ownership and borrowing.
The conventional explanation is technical: Rust tracks which part of a program owns a value, controls how references to that value may exist, and uses these rules to provide memory-safety guarantees without a garbage collector.
For someone writing TypeScript, that can initially seem irrelevant. V8 already manages memory. We do not call free(). We rarely reason about stack versus heap. We pass objects between functions without negotiating lifetimes with the compiler.
This interpretation misses the deeper idea behind ownership.
Ownership asks:
Who is responsible for this thing now?
That question applies to almost every significant object in a web application.
Who owns:
- a database transaction?
- a request-scoped authentication object?
- an open stream?
- a cache entry?
- a mutable configuration object?
- an
AbortController? - a WebSocket?
- a large parsed document?
- a temporary file?
- a subscription?
- a connection from a pool?
- a reactive Vue object?
- the result of an HTTP request?
JavaScript's garbage collector solves one narrow version of this problem:
Is this memory still reachable?It does not answer:
Should this resource still exist?V8's collector is highly sophisticated. Modern V8 uses generational collection, concurrent and parallel techniques, and extensive runtime optimisation. Those mechanisms concern memory reachability and runtime performance, not application semantics.
A leaked JavaScript object is therefore rarely an object the garbage collector failed to understand. Quite often the collector understands it perfectly. Your program is simply still referring to something it should have stopped referring to.
This distinction is profound.
Rust makes lifetime problems visible because the compiler forces them into the language. JavaScript lets them remain architectural.
Learning Rust trains you to see them anyway.
Consider a conventional Node application.
A request arrives. Middleware establishes authentication. Another layer adds a correlation ID. A repository acquires database data. Several services call external APIs. Some data enters a cache. Logging context propagates through asynchronous calls. Perhaps a stream is opened. Perhaps an event listener is attached.
The request completes.
What belongs to the process?
What belonged only to the request?
What can survive?
What must disappear?
What can safely be shared with the next request?
JavaScript does not force you to answer these questions. Rust does. That makes the Rust programmer unusually suspicious of accidental shared state.
This suspicion is healthy in Node.
Node provides AsyncLocalStorage specifically to propagate state across asynchronous operations during an asynchronous lifetime such as a web request. The Node documentation describes it as analogous to thread-local storage in other environments.
The existence of such an API illustrates the architectural issue perfectly. Request state has a lifetime. It should not accidentally become process state.
A useful Rust-informed rule for JavaScript is therefore:
Make the lifetime of state correspond to the lifetime of the thing it describes.
Configuration may be process-scoped. Authentication is normally request-scoped. A database transaction belongs to one operation. A UI form state belongs to one interaction. A cache entry may survive many requests but should still have an explicit eviction policy.
This sounds banal until one begins inspecting real JavaScript systems.
Then it becomes architecture.
Perhaps the most useful Rust concept for TypeScript programmers is the enum.
Rust enums allow a value to be exactly one member of a defined set of alternatives. Option represents presence or absence. Result represents success or recoverable failure. Pattern matching then forces the programmer to confront these states explicitly.
JavaScript traditionally represented these situations by convention.
A function might return:
User | nullunless it throws. Except sometimes it returns undefined. And authentication failures throw an UnauthorizedError. Unless the user does not exist, in which case it returns null. And database failures throw something supplied by the database driver.
The function therefore has a real return type something like:
User
| NotFound
| Unauthorized
| DatabaseFailure
| ProgrammingErrorbut only the first state exists in its declared model.
Rust teaches a better habit:
Model the states that actually exist.
TypeScript is surprisingly good at this.
type FindUserResult =
| { kind: 'found'; user: User }
| { kind: 'not-found' }
| { kind: 'forbidden' }
| { kind: 'unavailable'; reason: string }Now the caller sees the actual domain.
function respond(result: FindUserResult): Response {
switch (result.kind) {
case 'found':
return Response.json(result.user)
case 'not-found':
return new Response(null, { status: 404 })
case 'forbidden':
return new Response(null, { status: 403 })
case 'unavailable':
return new Response(result.reason, { status: 503 })
default:
return assertNever(result)
}
}
function assertNever(value: never): never {
throw new Error(Unexpected state: ${JSON.stringify(value)})
}
This is not pretending TypeScript is Rust. It uses a native TypeScript strength: discriminated unions. TypeScript can narrow such unions and use never to perform exhaustiveness checking.
The improvement is architectural. Unwanted combinations become difficult to represent.
Instead of:
{
loading: boolean
error?: Error
data?: User
}where loading, error and data can theoretically coexist in nonsense combinations, write:
type UserState =
| { state: 'loading' }
| { state: 'ready'; user: User }
| { state: 'failed'; error: Error }This applies equally well inside Vue components, Pinia stores, Hono services and Nuxt server endpoints.
Rust has taught us something important:
Boolean fields are frequently poor substitutes for states.
JavaScript developers often divide failures into two categories: something returned, and something thrown.
That distinction is too primitive.
Rust explicitly separates recoverable errors represented through Result from unrecoverable situations represented through panic. JavaScript cannot copy this mechanism exactly, and should not try. It should copy the distinction.
Consider:
const user = await repository.getUser(id)Several things might happen. The user exists. The user does not exist. The caller lacks permission. The database is temporarily unavailable. The repository encounters corrupt data. The programmer passed an impossible value because of a bug.
These are not equivalent failures.
A missing user may be ordinary domain behaviour. A database timeout is an infrastructure failure. Invalid internal state is probably a programming error.
When all three become throw new Error(), the architecture loses information.
Rust encourages a useful design discipline:
Expected failure belongs in the type system. Unexpected failure belongs in the failure mechanism.
That does not require a fashionable Result library in every TypeScript project. Sometimes a discriminated union is enough. Sometimes HTTP status is the right external representation. Sometimes throwing is entirely appropriate. The important part is making the distinction intentionally.
The purpose is to stop using exceptions as an undocumented second return channel.
Node presents a peculiar illusion.
Because JavaScript code uses async and await, it is easy to begin thinking of the system as massively concurrent. It is — but only in a particular sense.
Node's architecture relies heavily on an event loop and a relatively small number of worker threads. The Node project explicitly warns server developers that expensive callbacks can block the event loop and penalise other clients. Its recommendation is essentially one of computational fairness: the work performed for any individual client at a particular point should remain small.
This is precisely the kind of issue Rust makes difficult to ignore. Rust's concurrency model distinguishes whether values can safely move between or be shared across threads through concepts such as Send and Sync.
JavaScript has no equivalent compile-time contract. The architectural questions remain:
Can this work execute concurrently?
Should it?
What state does it share?
What happens under cancellation?
How much CPU can one request consume?
What happens when 2,000 requests perform this operation simultaneously?
What applies backpressure?
What owns the work after the HTTP client disappears?
These questions matter far more than whether the code contains Promise.all().
Suppose a handler performs 200 ms of synchronous CPU work. Writing:
async function calculate() {
return expensiveCalculation()
}does not make the calculation asynchronous in the relevant sense. The JavaScript still consumes CPU on the executing thread.
Node specifically recommends worker threads for CPU-intensive JavaScript work, and notes they provide little benefit for ordinary I/O-heavy workloads where Node's existing asynchronous I/O mechanisms are generally better.
This leads to one of the strongest Rust lessons for Node developers:
Concurrency is a resource-management problem, not an async syntax problem.
Once you understand that, application design changes. Queues acquire limits. Parallelism becomes bounded. Cancellation becomes part of API design. Timeouts are propagated. Large CPU jobs acquire their own execution boundary. Backpressure stops being an implementation detail.
Hono is particularly interesting here.
Its significance is not that its router is fast, although performance was part of its original appeal. Its more important architectural decision is that it centres the Web Platform itself.
Hono operates using standard abstractions such as Request, Response, Headers, URL and fetch, enabling the same application model across multiple JavaScript runtimes.
That encourages a form of architectural austerity. The HTTP layer can become very thin:
Request
↓
parse / validate
↓
domain operation
↓
explicit result
↓
ResponseThat shape resembles good Rust services — not because Rust uses the same APIs, but because the architecture has clear boundaries.
The request owns request-specific context. Input is validated at the boundary. Domain code receives valid values rather than arbitrary transport objects. Infrastructure is injected through explicit dependencies. Domain results return to the transport layer. The transport converts them into HTTP.
This is much better than allowing Hono's Context object to migrate through twenty layers of application code.
A context object is convenient. A context object passed everywhere eventually becomes a service locator. Then every function can theoretically access HTTP headers, authentication, runtime environment, bindings, cookies, response state, logging and request metadata. Dependencies become invisible.
Rust would make such unrestricted implicit access difficult to construct naturally. Its culture instead encourages narrow function inputs and explicit ownership.
Hono benefits from the same discipline.
Use the framework context at the edge. Extract what the application needs. Then leave HTTP behind.
There is a larger architectural change behind Hono.
Node itself now implements many Web Platform APIs. Its fetch() is browser-compatible, while Web Streams provide implementations of the WHATWG streaming model alongside Node's historical stream abstractions.
Hono pushes this considerably further by making those standards the foundation of its framework model.
The consequence is subtle. For much of Node's history, developers effectively wrote:
a Node application.Increasingly, it is possible to write:
a web server application that currently runs on Node.That difference matters. The second system has a portable core and a runtime adapter. This is conceptually close to the way a good Rust program separates domain logic from OS, network or framework infrastructure.
The deeper lesson is therefore not "use fewer Node APIs". It is:
Distinguish capabilities from implementations.
Your application needs:
KeyValueStorenot necessarily Redis.
It needs:
Clocknot Date.now() scattered through thirty files.
It needs:
UserRepositorynot Prisma exposed throughout the domain.
It needs:
HttpClientor perhaps simply standard fetch.
It needs a source of configuration, not direct process.env access from arbitrary modules.
This architecture makes testing easier. More importantly, it makes replacement possible. That becomes increasingly valuable when the same Hono application may run on Node today, Cloudflare Workers tomorrow, or Bun in another deployment. Hono even provides runtime adapter facilities for differences such as environment variables across platforms.
Rust programmers would recognise the philosophy immediately: keep the core model stable, and push platform-specific behaviour toward the boundary.
Nuxt adds a complication. It is not merely a server framework. It combines client application, Vue reactivity, server rendering, routing, build tooling and server infrastructure.
Modern Nuxt uses Nitro as its server engine, and Nuxt 4 can target traditional Node servers as well as serverless and edge environments.
This distinction now matters operationally: Nuxt 4 is the current major version, and its upgrade guide is where new work should be planned from, rather than treating Nuxt 3 as the platform of record.
Rust thinking becomes useful in Nuxt in four particular places.
Request ownership
Server code must distinguish application-global state from request state.
A singleton created during process initialisation may live far longer than the request that originally touched it. Anything containing authentication, locale, tenant, transaction or user-specific data deserves explicit lifetime reasoning.
Reactive ownership
Vue makes sharing reactive references extremely convenient. Convenience can conceal ownership.
Who is allowed to mutate this object? Is it canonical server state? A client-side copy? A cached value? Form state? Optimistic state? Derived state?
One of the easiest ways to create difficult Vue systems is to allow the same mutable object to occupy several conceptual roles.
Rust's instinct would be to separate them. A DTO from the server may be immutable application data. A form can own a mutable working copy. A computed value can be derived. A save operation creates a new server representation.
The exact implementation is JavaScript. The model is ownership.
Server and client boundaries
A Nuxt application crosses an unusually important boundary during SSR and hydration. Data moves from database and services into server-rendering logic, becomes serialised, moves through HTML or payloads, and becomes client state.
Rust teaches developers to take such transitions seriously.
Treat the serialisation boundary almost like a protocol. Do not casually send internal database entities to the browser. Create transport models intentionally. Validate external inputs. Make server-only capabilities impossible to reach from shared client modules.
Runtime portability
Nitro's deployment model creates the same architectural pressure as Hono.
Code that assumes local filesystem access, long-lived processes, Node-specific globals or unrestricted TCP connections may work perfectly under one Nitro deployment preset and be conceptually wrong under another.
A Rust-influenced architect asks about capabilities before APIs. That is exactly the right question.
Rust strongly rewards data-oriented thinking. A struct normally represents something. An enum normally represents one of several possible things.
JavaScript objects are far more permissive. The same object can gradually acquire properties:
user.authorized = true
user.permissions = permissions
user.profile = profile
user.loaded = trueBy the time it reaches the fifth function, nobody quite knows what a user is anymore.
This pattern is common because JavaScript makes incremental mutation easy. Rust encourages the opposite instinct: construct values representing meaningful states, then pass them onward.
This is valuable far beyond type safety. It reduces temporal coupling.
Consider the difference between:
create user
→ enrich user
→ authorize user
→ decorate user
→ mutate user againand:
Credentials
↓
AuthenticatedIdentity
↓
AuthorizedIdentity
↓
UserViewThe second design makes transitions visible. That often produces slightly more types and dramatically less ambiguity.
For large TypeScript systems, this may be one of the highest-return lessons Rust can offer.
JavaScript developers do not need a borrow checker. They frequently need to ask borrow-checker questions.
Suppose a function receives an object. Does it:
- read it?
- retain it?
- mutate it?
- transfer it somewhere?
- attach callbacks to it?
- place it in a cache?
- expose it to another request?
- close something contained within it?
A TypeScript signature usually does not tell you.
process(config: Config): Promise<Result>may mean almost anything.
Rust makes mutation and ownership transfer much harder to hide. JavaScript architecture should compensate by making intentions visible.
Use readonly where appropriate. Prefer functions without hidden mutation. Keep mutable structures locally owned. Avoid passing large mutable bags of application state through every layer. Copy when isolation is valuable. Share when sharing is intentional. And document functions whose semantics include retention or mutation.
There is no virtue in manually reconstructing Rust's ownership system inside TypeScript. There is great virtue in adopting its suspicion of invisible side effects.
There is another trap.
A developer learns Rust, becomes fascinated by allocation, copying and memory layout, and begins treating JavaScript as badly implemented Rust.
This is a mistake.
JavaScript engines are designed around JavaScript workloads. V8's garbage collector explicitly exploits the generational observation that many newly allocated objects die quickly. Allocating a short-lived JavaScript object is therefore not automatically an expensive architectural failure.
Likewise, V8 performs extensive representation and optimisation work internally. Its pointer-compression work alone demonstrates how far removed ordinary JavaScript source code is from a naïve "every object is an expensive heap object" mental model.
Rust knowledge should therefore improve JavaScript architecture rather than produce superstition.
Do not avoid creating objects merely because Rust taught you allocations have costs. Do not mutate shared structures merely to avoid copying. Do not replace readable TypeScript with typed arrays unless measurement justifies it. Do not construct elaborate Result abstractions merely because algebraic types are beautiful. Do not make every interface generic. And do not optimise code whose limiting factor is a network request taking 80 milliseconds.
The Rust lesson worth importing is not:
allocations are bad.It is:
resources have costs; understand the costs that actually matter.That is a much more powerful idea.
One of the most underdeveloped ideas in ordinary application JavaScript is backpressure.
Imagine an API receives 10,000 jobs. The naïve JavaScript solution is seductive:
await Promise.all(jobs.map(processJob))It is also frequently wrong. You may now have 10,000 database operations, 10,000 outgoing HTTP requests, 10,000 large objects, 10,000 pending promises, or some unfortunate combination of all four.
Promise.all describes aggregation. It does not provide capacity management.
A systems-language mentality asks a different question:
How many of these operations may exist simultaneously?
Perhaps the correct answer is 8. Or 50. Or one per database connection. Or one per CPU. Or as many as an external API's rate limit permits.
This is Rust thinking at its most useful — not because Rust automatically solves application backpressure, because it does not, but because systems programming creates an instinct that resources are finite.
JavaScript abstractions sometimes make them appear infinite. They are not.
There is another idea that becomes clearer through this lens.
Suppose a browser requests an expensive report. The user navigates away after 300 milliseconds.
The server continues: database query, external request, calculation, rendering, logging, perhaps another HTTP request.
Who owns that computation now?
Nobody wants the result. Yet the work continues.
This is a lifetime problem.
Modern JavaScript provides cancellation mechanisms such as AbortController and AbortSignal; Node exposes these Web-compatible primitives for Promise-oriented APIs.
The architectural lesson is to propagate cancellation through layers rather than terminating it at the HTTP handler. Think of the signal as part of the operation.
HTTP request
│
├── lifetime
├── deadline
├── identity
└── cancellation
↓
application
↓
repository
↓
external APIRust programmers might describe the issue using lifetimes and task ownership. JavaScript developers should think the same way even if the compiler does not.
A task that outlives its usefulness is still a leak. It may not be a memory leak. It is a work leak.
So far we have discussed Rust without using Rust. There are places where a modern JavaScript architecture should actually introduce it.
The wrong criterion is:
Rust is faster.The correct criterion is:
Does this component have sufficiently different computational characteristics to justify a separate execution model?Good candidates include certain forms of large-scale parsing, compression, image or signal processing, cryptographic work not already delegated to native implementations, search and index transformations, high-volume deterministic ingestion, binary protocols, simulation, CPU-intensive ranking, specialised data structures, and other workloads where predictable CPU and memory behaviour materially matters.
The Node documentation itself draws essentially the same architectural boundary by recommending worker threads for CPU-intensive JavaScript rather than ordinary I/O.
Rust provides another option. The component can become a native module, a WebAssembly module, a command-line processing component, a queue worker, or a separate service.
The decision should be based on boundaries.
If 97 per cent of an application performs database queries, HTTP orchestration and template rendering, rewriting it in Rust may achieve little. If three per cent performs 70 per cent of its CPU work, that three per cent is much more interesting.
This architecture is better than ideological rewrites. JavaScript remains where JavaScript is excellent. Rust appears where its characteristics change the economics of the system.
There is a natural architecture here.
Hono handles HTTP. It validates input. It performs authentication. It talks to ordinary web infrastructure. Most domain logic remains TypeScript. Expensive or specialised computation crosses a narrow boundary into Rust.
That boundary might initially be:
Hono
↓
Rust serviceover HTTP. Later it might become:
Hono
↓
Wasmor a native binding where latency justifies the additional coupling.
Hono's portability makes this particularly attractive because the HTTP application itself need not be committed to Node. Its documentation already includes runtimes ranging from traditional JavaScript engines to WebAssembly and WASI environments.
This begins to resemble a genuinely modern full-stack architecture:
Browser
│
Nuxt 4
│
┌─────────┴─────────┐
│ │
Nitro APIs Hono APIs
│ │
└─────────┬─────────┘
│
TypeScript domain
│
┌───────────┼────────────┐
│ │ │
SQL external queue
APIs
│
Rust worker
│
CPU-heavy workWhat matters is that every boundary in that diagram has a reason, rather than that the stack happens to contain two languages.
Many bad software systems are dishonest. Not maliciously. Structurally.
A function looks synchronous but performs hidden network activity. An object looks immutable but is mutated elsewhere. A value looks optional but is actually required. A return type describes success but not expected failure. A service appears stateless but retains state between requests. An asynchronous function appears cheap but monopolises CPU. A shared object appears convenient but has no clear owner. A framework abstraction appears portable but contains hidden Node-specific dependencies.
Rust's greatest contribution to a JavaScript architect is discomfort with this ambiguity.
Rust repeatedly demands that the programmer acknowledge reality: this value may not exist; this operation may fail; this reference cannot live forever; this state cannot be shared safely; this value moved; this case has not been handled.
TypeScript cannot enforce all of those propositions. Architecture can.
For a serious Node, Hono or Nuxt system, I would translate Rust thinking into twelve practical rules.
- Model states, not boolean combinations. Prefer discriminated unions when an entity genuinely exists in mutually exclusive states.
- Distinguish expected failures from programming failures. Not everything belongs in an exception.
- Give mutable state a clear owner. Shared mutable state should be rare and deliberate.
- Treat request state as request state. Never allow request-scoped information to accidentally become process-scoped.
- Keep framework objects near framework boundaries. Hono
Context, Nuxt event objects and database-specific records should not become universal domain types.
- Parse once at the boundary. Convert external uncertainty into trusted internal types as early as possible.
- Bound concurrency.
Promise.all()is not a capacity-planning strategy.
- Propagate cancellation and deadlines. Operations should not casually outlive the request or job that created them.
- Separate computational work from orchestration. CPU-heavy operations may need workers, Rust or another execution boundary.
- Prefer platform capabilities to platform implementations. Web Standards, narrow ports and adapters make Hono and Nitro genuinely portable.
- Do not cargo-cult Rust's low-level optimisation concerns into JavaScript. Measure first.
- Make ownership visible even when the compiler does not require it. The absence of a borrow checker does not imply the absence of lifetimes.
These rules produce TypeScript that still looks like TypeScript. That is important. The goal is a JavaScript system whose behaviour is easier to reason about.
This leads to an interesting conclusion. A JavaScript architect may obtain enormous value from Rust without placing a single .rs file into the production application.
Learning Rust changes the questions.
Before Rust:
Can I pass this object here?After Rust:
Who owns it after I do?Before:
Can this return null?After:
What states does this operation actually have?Before:
Can these promises run simultaneously?After:
What resource bounds their concurrency?Before:
Will garbage collection clean this up?After:
Why is the application still retaining it?Before:
Can this service call the database?After:
Should this layer know that the database exists?Before:
Does this work in Node?After:
Which runtime capability does this actually require?Those are architectural questions. They matter considerably more than syntax.
There is a historical irony here.
JavaScript once lived almost entirely inside browser pages. Then Node transformed it into a server language. Frameworks subsequently built increasingly elaborate abstractions around the Node environment.
Now something different is happening. The abstraction layer is moving downward again.
Request. Response. fetch. Streams. URLs. Abort signals. Portable deployment targets. Edge runtimes. Workers. WebAssembly.
Hono embodies this transition particularly clearly. Nitro and Nuxt participate in it from the full-stack side. Node itself increasingly implements Web Platform primitives.
The resulting ecosystem is simultaneously becoming higher level and more systems-oriented. Higher level because developers can deploy the same application across radically different infrastructure. More systems-oriented because those differences make questions of capability, lifetime, concurrency, memory, streaming and portability impossible to ignore.
This is exactly the territory Rust trains developers to think about.
For a JavaScript developer in 2026, Rust should not necessarily be viewed as the language that replaces JavaScript. It may be more valuable as the language that clarifies JavaScript.
It teaches that state deserves structure. Failure deserves representation. Mutation deserves an owner. Concurrency deserves limits. Resources deserve lifetimes. Infrastructure deserves boundaries. And performance deserves measurement rather than folklore.
Those principles fit Node exceptionally well because its event-loop architecture depends on disciplined resource use. They fit Hono perhaps even better because Hono's Web-Standards-first design encourages a small transport layer around portable application logic. And they fit Nuxt because a contemporary Nuxt application spans server, browser, SSR, reactive state and multiple possible deployment runtimes — all environments where poorly defined ownership and state boundaries eventually become expensive.
The lesson is therefore not:
write JavaScript as if it were Rust.
That would produce bad JavaScript.
The better lesson is:
think about JavaScript with some of the questions Rust refuses to let you avoid.
Then let JavaScript remain JavaScript. Use its garbage collector. Use its expressive object model. Use TypeScript's structural typing. Use promises. Use Vue's reactivity. Use Hono's minimalism. Use Nitro's portability. And when a genuinely CPU-intensive, memory-sensitive or deterministic component appears, perhaps use Rust there too.
The mature architecture is a system in which every abstraction has an intelligible lifetime, every important state has a name, every expensive resource has a boundary, and every language is used for the part of the problem it is good at solving. That is a different achievement from one language defeating another.
Rust's contribution to such a system may be several thousand lines of production code. Or none at all.
Either way, learning it can permanently alter the architecture.
