Show HN: Q⊗DASH – Rust/Python quantum operator framework for graph-based QC

3 points

7 months ago

I’ve released an experimental quantum computing framework that grew out of my own operator/graph work: Q⊗DASH (MetatronQSO)

Rust core crate: metatron-qso-rs Python package: metatron_qso

GitHub: https://github.com/LashSesh/qso crates.io: https://crates.io/crates/metatron-qso-rs PyPI: https://pypi.org/project/metatron_qso/

# What it is

MetatronQSO is a Rust-first quantum operator framework with Python bindings. It focuses on graph- and operator-based algorithms: quantum walks, VQE, QAOA-style circuits and related experiments.

Core ideas: - Rust library for state evolution, circuits, walks and variational algorithms - PyO3-based Python SDK mirroring the same concepts - Backend abstraction (local simulator now, room for hardware providers via traits) - A nontrivial default geometry (a Metatron-cube–style graph) instead of toy line/grid graphs

The goal is not “yet another Qiskit wrapper”, but a self-contained operator core you can bend into your own models.

# Architecture (high level)

The workspace is organized as multiple crates, the key ones: - metatron-qso-rs: core quantum library (state, operators, circuits, walks, VQE/QAOA, example binaries) - metatron_qso_py: Python bindings - backend/telemetry crates for plugging in execution backends and exposing basic metrics

Everything is regular Rust + Cargo, with Python wheels built via maturin.

# Current status

metatron-qso-rs published on crates.io (0.1.x) metatron_qso published on PyPI (0.1.x) CI builds Rust + Python, runs tests and some benchmarks There are docs/notes in the repo explaining the operator model and backend design

It’s early-stage, but it compiles, runs examples, and is usable for experiments if you’re comfortable with Rust (or happy to drive it from Python).

# What I’d like feedback on

Does the Rust API surface feel idiomatic and composable? For Python users: is the current binding layer something you’d realistically work with, or would you expect a higher-level abstraction? Is the backend abstraction (local simulator now, future hardware later) structured in a way that’s easy to extend? Any obvious red flags in how I treat graphs/geometry as the primary object?

If you’re into quantum computing, graph-based algorithms, or unusual Rust workspaces, I’d appreciate any feedback, criticism, or ideas for where this should go next.