Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Roadmap] Incremental Rust modernization for HugeGraph core modules

Open
  • Is something wrong?
#3,110 4 comments 3 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Refactor
Clarity
Needs clarification
Activity status
Quiet
Tech stack
java, rust
Domain
backend, databases, distributed-systems

Research direction

This is a parent roadmap rather than a concrete code task, with no file or test entry point named. Start by reading the contribution guide and the checklist, then choose a bounded candidate such as interoperability boundaries, differential fixtures, or benchmarks. Done means an approved, scoped child issue with owner or mentor, compatibility and test criteria, benchmarks, and rollout or rollback requirements.

Written by the indexing model from the issue text.

Description

feature help wanted improvement

Goal

Explore an incremental Rust implementation for selected HugeGraph Server, HStore, and PD components, especially performance- or memory-sensitive paths where Rust can provide measurable safety and efficiency benefits.

This is a parent tracking issue, not a commitment to rewrite the whole server. The current implementation remains the compatibility baseline, and Java/Rust components may coexist behind stable process, protocol, or storage boundaries.

Roadmap at a glance

Toolchain foundations
        │
        v
┌─ This repository ─────────────────┐
│  Server core -> HStore -> PD      │
└───────────────────────────────────┘
        │
        v
Computer kernels -> Vermeer/OLAP

Each arrow is a review gate, not an automatic rewrite.

Proposed priority

  1. Server core
    • Begin with bounded leaf components, memory management, codecs, or performance-sensitive data structures rather than the whole request path.
    • Preserve REST/Gremlin behavior, authentication, observability, and plugin contracts.
  2. HStore
    • Evaluate storage/replication paths only after workload baselines, on-disk and wire compatibility, failure recovery, and rolling-upgrade requirements are explicit.
  3. PD
    • Evaluate scheduling and metadata components after their distributed-system invariants and compatibility contract are covered by repeatable tests.

The sequence may change based on benchmark evidence and maintainer consensus.

Delivery model

proposal/RFC -> isolated component -> differential/fault tests
             -> benchmark -> opt-in deployment -> staged adoption

Planning guardrails (required)

Before implementation starts, each child issue must define:

  • scope, owner/mentor, and non-goals;
  • API, protocol, storage-format, and operational compatibility;
  • differential, concurrency, fault-injection, and upgrade/rollback tests;
  • reproducible latency, throughput, memory, and recovery benchmarks;
  • security/dependency checks and supported platforms;
  • observability, 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.

Candidate work items

  • Select the first small server-side proof of concept
  • Document stable Java/Rust interoperability boundaries
  • Build shared differential and compatibility test fixtures
  • Establish representative OLTP and storage workload baselines
  • Define CI, packaging, security, and release conventions
  • Define rolling-upgrade and rollback requirements before HStore/PD work
  • 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 (this issue): apache/hugegraph#3110
  • Computer / Vermeer: apache/hugegraph-computer#355
  • Documentation hub: apache/hugegraph-doc#462

How to participate

Interested in open source, Rust, databases, distributed systems, storage engines, or infrastructure? Comment with the area you want to work on and any relevant experience. RFC review, failure-model analysis, benchmarks, tests, and documentation are all valuable.

First-time contributors can start with the HugeGraph contribution guide and the repository's good first issue / help wanted tasks.

Dominant language
Java
Stars
3.2k
Forks
640
Avg merge
4d 10h
Merged PRs (30d)
19

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/hugegraph

All issues in apache/hugegraph

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.