Emir Baycan Posted on May 31 Why we chose a Rust template engine and Go APIs # rust # go # architecture # webdev When people hear that one studio runs 7+ products, the first question is always about the stack. The honest answer is that the stack is the reason it's possible at all. Here is why Kalenuxer, our in-house engine, splits into a Rust template engine and a set of Go APIs, and what that split buys us. The problem: most pages are not dynamic Across our portfolio, the overwhelming majority of pages are content: articles, topic pages, archives, localized variants. They change when we publish, not on every request. Rendering that kind of page per-request is wasted work, and it is the single biggest source of slowness and operational cost in most content sites. So we treat content rendering as a build step, not a runtime concern. Why Rust for the template engine The template engine compiles a product's content into static, deterministic HTML. A product with thousands of localized pages builds in one pass. We picked Rust for three reasons: Determinism. The same input always produces byte-identical output. That makes diffs meaningful, caching trivial, and regressions easy to spot. Speed at scale. Building 40,000+ pages across the portfolio has to be fast enough to run on every publish without becoming a bottleneck. Memory safety without a GC pause. A build that touches that many files benefits from tight, predictable memory behavior. The output is just files. Files are the easiest thing in the world to serve, cache, and reason about. Why Go for the APIs The parts that genuinely need to be dynamic, admin tooling, search, forms, the bits of each product that talk to a database, run as Go services. Fast to write, fast to run. Go's concurrency model fits request-handling naturally, and the toolchain keeps services small and easy to deploy. Easy to operate. A single static binary per service is a gift when you are the one running it in production, not handing it off. Bor
LIVE