Skip to content

Why Rust?

Flow-Like’s core is built in Rust, providing the performance, safety, and reliability needed for a workflow automation platform.

Rust’s type system enables Flow-Like’s fully-typed workflows:

  • Compile-time guarantees: Catch errors before runtime
  • Explicit absence and failure: Option<T> and Result<T, E> make callers handle those states
  • Trait-based abstractions: Nodes, pins, and storage backends share common interfaces

Workflow execution benefits from:

  • Zero-cost abstractions: High-level code compiles to efficient machine code
  • No garbage collector: Predictable latency for real-time workflows
  • Parallel execution: Safe concurrency with async/await and Rayon

For a platform handling user-defined workflows:

  • Safe ownership and borrowing: Safe Rust prevents many use-after-free, aliasing, and data-race bugs; indexing remains bounds-checked
  • Visible native boundaries: ONNX, LanceDB, and other native integrations keep their unsafe/FFI boundaries reviewable
  • Controlled concurrency: Shared state has to satisfy Rust’s thread-safety contracts before it can cross task and thread boundaries

Key Rust crates in the workspace include:

PathCrateResponsibility
packages/core/flow-likeCore workflow library
packages/types/flow-like-typesShared domain types
packages/storage/flow-like-storageStorage abstraction
packages/bits/flow-like-bitsReusable components
packages/model-provider/flow-like-model-providerAI and ML providers
packages/api/flow-like-apiREST API
packages/executor/flow-like-executorExecution runtime
packages/catalog/flow-like-catalogBuilt-in node implementations
packages/catalog-macros/flow-like-catalog-macrosProcedural macros for the catalog

The workspace also contains supporting crates. Treat the root Cargo.toml member list as the authoritative inventory.

DependencyPurpose
tokioAsync runtime
axumHTTP framework for API
serdeSerialization/deserialization
object_storeCloud storage abstraction
lancedbVector database for embeddings
rig-coreLLM integrations
ortONNX runtime for local ML
tauriDesktop app framework

Flow-Like uses Rust Edition 2024 for most packages. Some executor, compiler, and WASM crates remain on Edition 2021, so check the crate’s own Cargo.toml before relying on edition-specific syntax.

  • Latest language features
  • Improved async ergonomics
  • Better compile-time optimizations

Flow-Like uses async Rust extensively:

#[async_trait]
impl NodeLogic for HttpRequestNode {
async fn run(&self, context: &mut ExecutionContext) -> anyhow::Result<()> {
let url: String = context.evaluate_pin("url").await?;
let response = reqwest::get(&url).await?;
context.set_pin_value("body", json!(response.text().await?)).await?;
Ok(())
}
}

The async_trait crate enables async trait methods, and tokio provides the runtime.

Conditional compilation selects deployment and runtime capabilities. These examples come from different workspace crates rather than one shared feature table:

[features]
# Enable local ML inference (adds ~100MB to binary)
local-ml = ["flow-like-model-provider/local-ml"]
# Enable Tauri-specific APIs
tauri = ["flow-like-storage/tauri"]
# Enable Kubernetes execution backend
kubernetes = ["kube", "k8s-openapi"]

Flow-Like uses anyhow for error handling in application code and thiserror for library errors:

use anyhow::{Result, Context};
async fn load_board(id: &str) -> Result<Board> {
let bytes = storage
.get(path)
.await
.context("Failed to load board from storage")?;
serde_json::from_slice(&bytes)
.context("Failed to deserialize board")
}

The Rust backend compiles for multiple targets:

  • macOS: aarch64-apple-darwin, x86_64-apple-darwin
  • Windows: x86_64-pc-windows-msvc, aarch64-pc-windows-msvc
  • Linux: x86_64-unknown-linux-gnu
  • iOS: aarch64-apple-ios (with special ONNX handling)

Recommended tools for working with the Rust codebase:

Terminal window
# Format code
cargo fmt
# Lint with Clippy
cargo clippy
# Run tests
cargo test
# Check compilation without building
cargo check
# Run benchmarks
cargo bench -p flow-like-catalog