[Proposal] Resolving the "Warm-up Paradox" via a rewrite in Rust 🦀

[NersesAM]

Hey there,

I’ve been following the progress on Mittens and I really love the mission. Solving cold starts in Kubernetes is a massive pain point. However, looking at the current Go implementation, I can’t help but notice a bit of an architectural paradox: we are using a Garbage Collected (GC) runtime to solve latency spikes that are often caused by... Garbage Collection (and other runtime warm-up issues).

Have you considered rewriting Mittens in Rust?

I believe migrating the codebase would align much more closely with the project's goal of being a lightweight, transparent "sidecar" utility. Here are a few technical reasons why a Rust port would be superior for this specific use case:

1. Zero-Cost Sidecar Footprint

In a K8s environment, every MB counts for sidecars. By moving away from the Go runtime, we can eliminate the GC overhead entirely. A Rust implementation would offer:

• Deterministic Memory Usage: No heap spikes during the warm-up phase.
• Tiny Binaries: Using musl and strip, we could get the image size down to a fraction of the current Go build, speeding up pod pull times.

2. Fearless Concurrency with Tokio

While Goroutines are easy to spin up, they still require the Go scheduler to manage them. Using Tokio for the HTTP/gRPC probes would allow for much more granular control over the executor. We can ensure that the warm-up requests themselves never introduce jitter or contention into the node's CPU budget.

3. Type-Safe gRPC/HTTP Probes

Instead of relying on the current reflection-heavy approach, we could leverage Tonic and Prost. This would move the validation of warm-up payloads to compile-time.

• No nil pointer panics: Option<T> ensures we never crash while trying to warm up a target.
• Exhaustive Pattern Matching: Using Enums for the Provider logic means the compiler will literally refuse to build if a new protocol is added but not handled.

4. Error Handling & Correctness

Replacing the if err != nil boilerplate with the ? operator and Result types would make the core logic—specifically the timing and retry loops—much more ergonomic and less prone to "swallowed" errors that leave services "half-warm."

---

I've already started a small proof-of-concept (POC) using clap for the CLI and reqwest/tonic for the probing logic. It’s significantly more memory-efficient and avoids the "cold start" of the warm-up tool itself.

I'd be happy to discuss how we can start a mittens-rs branch or perhaps a gradual migration of the core logic.

Stay safe (and memory safe)! 🦀