Encore built a Rust runtime to run TypeScript — and it paid off

Why rewrite in Rust?
Encore began life as a Go-first framework. When the team moved to support TypeScript, it would have been easy — even tempting — to stick a TypeScript runtime on top or glue Node.js to the existing Go sidecar. Instead, it has been reported that the team chose to build a brand-new runtime in Rust. Why? Two reasons: they wanted a single, reusable core that could bind into multiple language runtimes (Prisma and Pydantic were cited as inspiration), and they wanted to move infrastructure work off the Node.js event loop so everything non-business could run multi-threaded on tokio. Short version: better reuse, better concurrency. Long version: fewer surprises at scale.
The sidecar prototype that failed fast
They tried the obvious first. A Go sidecar talking to Node.js over IPC sounded pragmatic. It wasn’t. It has been reported that serializing every DB query, pub/sub message and trace event across a process boundary cost them — benchmarks showed an extra 2–4 ms per request just from crossing that boundary, and a typical API call could hop the fence six or seven times. Operationally, two processes meant two sets of logs, two crash surfaces, and a lot more mean time to diagnose. Not worth the candle, the team decided, and so they moved into the single-process world with N-API bindings — but written in Rust via napi-rs.
What they shipped and why it matters
Two years and roughly 67,000 lines of Rust later, Encore shipped an atomic release that bundled three crates: the core runtime, JavaScript N-API bindings, and a TypeScript parser (public release #1073). The runtime now handles routing and request parsing, DB pooling and querying, multi-cloud pub/sub, distributed tracing, metrics, object storage, caching, and an API gateway powered by Pingora — while the TypeScript layer stays pure business logic. Architecturally each infrastructure concern is a lazily-initialized manager configured by protobufs: one set generated at compile time from your TypeScript, another telling the runtime which cloud implementations to use. The payoff is clear — lower latency, fewer ops headaches, and a path to add more languages without rewriting infrastructure. Will others follow suit? If you care about throughput and sane debugging, the Encore playbook is worth a hard look.
Sources: encore.dev, Hacker News
Comments