[Roadmap] Incremental Rust modernization for graph computing

## 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

```text
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:

1. Establish representative graph datasets, algorithm outputs, and performance baselines for Computer and Vermeer.
2. Prototype a small isolated kernel or I/O component with a stable boundary.
3. Validate multi-worker behavior, determinism, failure recovery, and resource use before expanding scope.
4. Consider broader Vermeer/OLAP migration only after the experiments show a clear maintenance and performance benefit.

## Delivery model

```text
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

- [ ] Define representative datasets and algorithm correctness fixtures
- [ ] Publish Computer and Vermeer performance/resource baselines
- [ ] Select one small proof-of-concept kernel or I/O path
- [ ] Decide the interoperability and packaging boundary
- [ ] Establish Rust CI, lint, dependency, and release conventions
- [ ] Validate local and multi-worker deployment paths
- [ ] Split approved work into newcomer-friendly child issues

This checklist will link to concrete child issues as proposals are accepted.

## Project-wide roadmap

- Toolchain: apache/hugegraph-toolchain#748
- Server / HStore / PD: apache/hugegraph#3110
- Computer / Vermeer (this issue): apache/hugegraph-computer#355
- Documentation hub: apache/hugegraph-doc#462

## 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](https://hugegraph.apache.org/docs/contribution-guidelines/contribute/) and the repository's `good first issue` / `help wanted` tasks.

Es werden keine Implementierungsdateien, Tests oder Einstiegspunkte genannt; dies ist eine übergeordnete Roadmap und keine direkt umsetzbare Aufgabe. Beginne mit der Prüfung der in Betracht kommenden Arbeitspunkte und der Planungsleitplanken. Definiere anschließend ein konkretes untergeordnetes Issue mit einer verantwortlichen Person, einem Umfang, Kompatibilitätsanforderungen, Benchmarks, Tests und Abnahmekriterien. Als abgeschlossen gilt die Aufgabe, wenn vor Beginn der Implementierung ein genehmigter, klar abgegrenzter Vorschlag für ein untergeordnetes Issue vorliegt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.