Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Rust Implementation of Apache Burr

未关闭
#653 3 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 4 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
停滞
技术栈
python, rust, wasm

调研方向

首先审查现有的 Python 实现,并围绕已记录的运行结果和规范化输出定义所提议的 golden/characterization tests。构建所提到的 Rust 项目骨架,然后根据既定的 parity 目标评估每个子系统—runtime、persistence、telemetry、server/UI API 和 CLI;完成意味着达成一致的 goldens 均通过,并且项目范围和其在 repository 中的位置都已确定。

由索引模型根据 Issue 内容生成。

描述

area/core kind/feature priority/low

Is your feature request related to a problem? Please describe.

I’d like to use Burr’s state-machine / action-graph approach in environments where Rust is the primary deployment/runtime (e.g., Rust microservices, single-binary distribution, memory-safety requirements, low-latency workloads, WASM targets, etc.).

Currently this means either running Burr as a separate Python service, embedding Python, or re-implementing similar functionality ad-hoc, each of which adds operational complexity and makes it harder to standardize on Burr as a core orchestration primitive across a Rust-heavy stack.

Describe the solution you'd like

I’d like to propose (and happily help implement) an officially supported or officially endorsed Rust implementation of Burr with the goal of full functional parity with the existing Python implementation, including:

  • Core runtime parity: actions, transitions, state semantics, sync/async execution, parallelism features, hooks, typing system behavior, etc.
  • Persistence & tracking parity: same data model and on-disk formats where applicable, so recorded runs are comparable/portable.
  • Telemetry/observability parity: compatible tracing/metrics behavior (and the same conceptual execution events).
  • Tracking server + UI parity: ideally, the existing UI can be used unchanged by matching the server API contract.
  • CLI parity: equivalent commands/subcommands and behavior, or a clearly documented mapping.

Proposed Implementation approach:

  • Define the spec as golden/characterization tests derived from the reference implementation (recorded runs + normalized outputs).
  • Develop the test suite with a complete Rust project skeleton first.
  • Develop subsystem-by-subsystem until all goldens pass and expanding coverage until parity is reached.

Questions for maintainers:

  • Would this be welcome as an official multi-language implementation or preferred as a community project first?
  • If official, should it live in this repo (subdir/workspace) or in a separate repo?

Describe alternatives you've considered

  • Rust wrapper around Python Burr (PyO3 / embedding Python) to reuse existing behavior but with Rust entry-points.
  • Running Burr as a separate Python service and integrating over HTTP/IPC from Rust (keeps Burr unchanged, but adds runtime/ops overhead).
  • Partial Rust port (core runtime only) while keeping the existing tracking server/UI and/or persistence layer in Python.
  • Implementing only server/API compatibility in Rust while leaving runtime execution to Python (or vice versa).
  • Using other Rust state-machine/workflow crates instead of Burr (but that forfeits Burr’s model, tooling, and existing ecosystem).
主要语言
Python
星标
2.6k
派生
209
平均合并
8 天 9 小时
30 天内合并 PR
26

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

apache/burr 的其他 Issue

查看 apache/burr 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。