Substratum.cloud

Appearance

ADR 07: Core Language Selection (Rust vs Go) ​

Status: Proposed Date: 2026-04-09

Context ​

We need to select a core language for the Substratum Sidecar, Gateway, and core domain logic. The system needs to handle high-throughput routing (multiplexing thousands of concurrent P2P connections) while maintaining a minimal memory footprint for background daemon execution on low-resource devices (e.g., Raspberry Pi, older laptops).

We evaluated the two dominant languages in the libp2p ecosystem: Go (go-libp2p) and Rust (rust-libp2p).

Decision ​

We propose using Rust for the core daemon, gateway, and domain logic, compiled to WASM where necessary for the frontend. The UI (SaaS Dashboard) will be built in TypeScript.

This creates a Polyglot Monorepo structure:

  1. The Rust Workspace (The Engine): crates/core, crates/p2p, crates/sidecar, crates/gateway.
  2. The TypeScript Workspace (The UI): apps/saas, apps/desktop-ui.

Consequences ​

  • Positive:
    • Memory Footprint: Predictable, flat memory usage with no Garbage Collection (GC) pauses. A background Rust node can sit comfortably under 15MB of RAM.
    • Modularity: rust-libp2p's NetworkBehaviour architecture perfectly aligns with our "Ports and Adapters / Module Swapping" philosophy, making it highly idiomatic to inject custom connection protectors (Swarm PSK).
    • Performance: Zero GC pauses for the high-throughput Gateway.
    • Portability: The core domain logic can be compiled to WebAssembly (WASM) to run Swarm PSK or Passport Receipt logic directly in a user's browser.
  • Negative:
    • Learning Curve: Rust has a steeper learning curve compared to Go or TypeScript.
    • Compilation Times: Slower build times compared to Go.
    • Polyglot Complexity: The UI must be built in a separate language/workspace, requiring tooling to manage a mixed Rust/TypeScript monorepo.