Goal
Explore an incremental Rust implementation for selected graph-computing components in HugeGraph Computer and Vermeer, focusing on kernels, data movement, memory efficiency, and operational simplicity where Rust offers a measurable advantage.
This is a parent tracking issue, not a commitment to replace the existing Java/Go systems wholesale. Existing algorithms, formats, and deployments remain the compatibility and performance baseline.
Roadmap at a glance
Toolchain -> Server core -> HStore -> PD
│
v
┌─ This repository ─────────────────────────────────────────────┐
│ Baselines -> isolated kernel/I/O -> multi-worker validation │
│ │ │
│ v │
│ broader Vermeer/OLAP scope │
└───────────────────────────────────────────────────────────────┘
Expansion happens only when correctness and benchmark gates pass.
Proposed priority
This work follows the shared Toolchain and Server foundations. Within this repository:
- Establish representative graph datasets, algorithm outputs, and performance baselines for Computer and Vermeer.
- Prototype a small isolated kernel or I/O component with a stable boundary.
- Validate multi-worker behavior, determinism, failure recovery, and resource use before expanding scope.
- Consider broader Vermeer/OLAP migration only after the experiments show a clear maintenance and performance benefit.
Delivery model
baseline -> proposal/RFC -> isolated kernel or I/O slice
-> result-parity + scale tests -> opt-in preview -> staged adoption
Planning guardrails (required)
Before implementation starts, each child issue must define:
- scope, owner/mentor, and non-goals;
- API/CLI/config, protocol, input/output/storage-format, algorithm, and operational compatibility;
- differential result parity/tolerance, determinism, concurrency, multi-worker, fault-injection, and upgrade/rollback tests, where applicable;
- reproducible latency, throughput, memory, scaling, cost, and recovery benchmarks;
- security/dependency checks and supported platforms;
- observability, packaging/deployment, coexistence, migration, and rollback plans;
- explicit acceptance criteria and user/operator/contributor documentation.
No large rewrite PR should start before its design and acceptance criteria are reviewed. Correctness, recoverability, and compatibility take precedence over headline benchmark numbers. Small, reviewable PRs and stable interoperability boundaries are required; an unplanned rewrite PR may be closed or asked to return to the RFC/design stage. Benchmark results must include datasets, hardware, configuration, and the current implementation used as the baseline.
Candidate work items
This checklist will link to concrete child issues as proposals are accepted.
Project-wide roadmap
How to participate
Interested in open source, Rust, graph algorithms, distributed computing, performance engineering, or infrastructure? Comment with the area you want to work on and any relevant experience. Algorithms, datasets, correctness tests, deployment work, and documentation are all useful entry points.
First-time contributors can start with the HugeGraph contribution guide and the repository's good first issue / help wanted tasks.
Goal
Explore an incremental Rust implementation for selected graph-computing components in HugeGraph Computer and Vermeer, focusing on kernels, data movement, memory efficiency, and operational simplicity where Rust offers a measurable advantage.
This is a parent tracking issue, not a commitment to replace the existing Java/Go systems wholesale. Existing algorithms, formats, and deployments remain the compatibility and performance baseline.
Roadmap at a glance
Proposed priority
This work follows the shared Toolchain and Server foundations. Within this repository:
Delivery model
Planning guardrails (required)
Before implementation starts, each child issue must define:
No large rewrite PR should start before its design and acceptance criteria are reviewed. Correctness, recoverability, and compatibility take precedence over headline benchmark numbers. Small, reviewable PRs and stable interoperability boundaries are required; an unplanned rewrite PR may be closed or asked to return to the RFC/design stage. Benchmark results must include datasets, hardware, configuration, and the current implementation used as the baseline.
Candidate work items
This checklist will link to concrete child issues as proposals are accepted.
Project-wide roadmap
How to participate
Interested in open source, Rust, graph algorithms, distributed computing, performance engineering, or infrastructure? Comment with the area you want to work on and any relevant experience. Algorithms, datasets, correctness tests, deployment work, and documentation are all useful entry points.
First-time contributors can start with the HugeGraph contribution guide and the repository's
good first issue/help wantedtasks.