[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.

No se nombran archivos de implementación, pruebas ni puntos de entrada; esto es una hoja de ruta principal, no una tarea directamente accionable. Empieza revisando los elementos de trabajo candidatos y las salvaguardas de planificación; después, define un issue secundario concreto con una persona responsable, alcance, requisitos de compatibilidad, benchmarks, pruebas y criterios de aceptación. Se considera completado cuando existe una propuesta aprobada y acotada para un issue secundario antes de comenzar la implementación.

Escrito por el modelo de indexación a partir del texto del issue.