Video summary

I spent six months rewriting everything in Rust

Main summary

Key takeaways

Technology

Overall premise / motivation

  • The creator says their software breaking after periods of inactivity pushed them to rewrite critical income-generating systems in Rust over ~6 months.
  • They rewrote not just backend components, but the APIs, tooling/data update pipelines, video editing workflows, and the websites themselves.

Background context: language lessons leading to Rust

  • JavaScript / Node.js: Provided modern server/DB thinking and enabled ecosystems around CLI tools, desktop apps, and build tooling.

  • Haskell: Hard to learn/share, and it highlighted that technical excellence isn’t enough—community, documentation, onboarding, and psychological safety matter.

  • Go (via Docker): Easy to adopt with supportive community. However, the creator felt they were constantly uncertain about “magic rules” and lacked confidence in writing correct Go.

Why Rust (selection of product/tech reasons)

  • Long-term contracting stack: They keep JavaScript plus one other language available; Rust became the “other” alongside JS.

  • Type system / expressiveness: Mentions enums and structs carrying data (learned previously in Haskell).

  • Cargo (package manager):

    • Centralized dependency management.
    • Tests built into workflows, encouraging more testing and catching issues earlier.

  • Safe vs unsafe Rust: Preference to avoid pointer-level programming unless necessary (e.g., embedded/low-level domains).

  • Community / inclusivity + empowerment: Rust’s website/community messaging and a supportive ecosystem felt similar to the empowerment they experienced with Node.js.

  • Capability spectrum: Rust’s reputation spans both:

    • Low-level/high-performance uses (drivers, networking, games, embedded)
    • High-level web/API development (framing Rust as “like JavaScript with types built in”)

Examples of Rust capabilities/tools (proof points)

  • CLI / argument parsing: clap
  • Game dev: bevy
  • GPU: wgpu (also referenced as used in Firefox’s WebGPU implementation)
  • Async runtime & async-await support: tokio
  • Web APIs / frameworks: axum
  • Embedded systems: embassy
  • Parallelism: rayon
  • Async vs alternatives: compares tokio with other async parsing/solutions
  • Serverless: cargo-lambda (build Rust binaries for AWS Lambda)

  • WebAssembly tooling: wasm-bindgen

  • Cross-language interoperability (key theme): Rust code can run inside JavaScript, Python, or Elixir contexts—enabling safety/performance benefits without requiring a full ecosystem switch.

Rewriting case study: “Rust Adventure” website (6-month rebuild)

  • The creator rebuilt a site used to host/distribute educational written/video content called Rust Adventure.
  • Earlier architecture:
    • Mostly serverless functions + JavaScript
    • Some Rust for a custom build system and parts of APIs

Main product requirements

  • SaaS features: user accounts, payments, multi-client handling
  • Integrations:
    • AWS Cognito (accounts)
    • Stripe (payments)
  • Multiple UIs: customer-facing + admin/content management

Database migration

  • Old DB: DynamoDB
  • New DB: PlanetScale hosted MySQL (test flavor)
    • Chosen for schema migration flexibility and to build admin tools to manage DB data.
    • Benefits include a git-branch-like workflow and safety guards.

API layer migration (GraphQL → REST)

  • Old API: AWS AppSync (GraphQL) with Rust-based resolvers Worked well with Cognito, but they disliked using Amplify as the query mechanism.

  • New API stack:

    • Axum + Tokio powering a MySQL-backed REST API
    • Emphasized:
      • Tight integration with the Tower ecosystem
      • Rust ecosystem examples
      • Preference for fewer heavy macros (better error messages)
      • Typed extractor-style design resembling a dependency-injection pattern

Deployment approach

  • Uses a Docker-friendly platform:
    • Chose Fly.io
    • Notes Fly.io uses wireguard for internal networking and Firecracker microVMs
    • States Fly.io is also written in Rust

Data access tooling

  • Mentions SQLx-style compile-time checking:
    • Queries are checked at compile time against DB schema
  • Notes that ORMs are also available.

Web UI in Rust: Wasm + Leptos (“can Rust do web UI?”)

  • The creator argues Rust web UI is feasible via WebAssembly (wasm): compiling non-JS languages to run in the browser.
  • Focus is on DOM-based UI (rather than purely canvas/native toolkits) to support mass-market accessibility and text layout.

UI framework choice

  • Considered: Dioxus, Sycamore, Yew, Leptos
  • Chose Leptos, especially because the project started before release and finished after Leptos v0.4.

Leptos capabilities mentioned

  • Server-side rendering + rehydration
  • Reactive signals (less reliance on a traditional virtual-DOM model)
  • Server functions
  • Quality-of-life features: integrating signals, server functions, and forms with action forms
  • Progressive enhancement: page works without mandatory JavaScript

How the rewrite feels / outcome

  • Built:
    • The main “Rust Adventure” site
    • An admin UI for content management
  • Stack used:
    • Axum for both UIs and the third API service
  • Result:
    • Claims it’s as good as a JavaScript-based site in maintainability and developer experience.

Drawbacks / tradeoffs for Rust + Wasm web apps

  • Lose access to much of the JavaScript ecosystem tooling, especially framework-integrated UI libraries (e.g., framer-motion).
  • Gain access to Rust crates (e.g., wgpu) and can integrate wasm-backed code with vanilla JS libraries.
  • Still need to build/maintain more UI pieces (e.g., using a web component for video playback).
  • Learning curve:
    • New wasm-specific optimization techniques
    • Managing download size and dependency weight can become important.

Ecosystem maturity issues

  • Rust wasm UI space is described as new, with fewer developers having years of experience.
  • Build-tool ecosystem differences:
    • Some JS capabilities (e.g., code splitting) don’t translate 1:1
    • wasm spec evolution impacts workflow development

Third-party integration gaps (examples)

  • Many services provide JS SDKs but no official Rust SDKs:
    • Stripe: no official Rust SDK, but integration is still possible (including Checkout and webhooks) via community-built approaches.
    • Cognito: AWS Rust SDK exists but is labeled developer preview (the author says it worked fine for them).

Bottom-line conclusion of the video

  • Rust is presented as a strong replacement for both high-level and systems needs:
    • servers, CLI tools, audio processing, and also web APIs and wasm-based web UI.
  • The creator claims:
    • Production websites in Rust are possible today, though early in adoption.
  • They also note other domains they didn’t cover (audio processing, XML generation, more CLI tools).

Main speakers / sources

  • Primary speaker: the video creator/narrator (author of the Rust rewrite project and “Rust Adventure” site).
  • Referenced sources/tools (not speakers): Rust language/community website and the libraries/frameworks mentioned, including Cargo, Tokio, Axum, Leptos, SQLx, Fly.io, PlanetScale, Wasm-bindgen, Stripe JS SDK, and the AWS SDK for Rust.

Original video