QCNEWS
IBM's open source quantum SDK now ships native bindings for the three languages where most scientific and HPC code actually lives, and they share the same library.
IBM's open-source quantum software development kit, Qiskit, has reorganized itself around a Rust core exposed through a C API, and the practical consequence is that Fortran, C++, and Julia, three languages that previously needed Python to reach quantum work, can now build and run circuits natively. The shift landed in Qiskit v2.0, released with bindings for those three languages alongside the existing Python SDK.
Until this release, Fortran, C++, and Julia code that wanted to reach a quantum backend had to do it through Python, which is already the de facto orchestration layer for most scientific and HPC workflows. The v2.0 architecture removes that detour by exposing the same Rust core that drives the Python front end through a documented C interface, and each new language binding links to the same shared Qiskit library.
That shared library is what makes the IBM Research announcement's interoperability claim concrete. A circuit defined in Fortran can be passed to C++ and run there without conversion. A Julia routine can hand a prepared circuit to a C++ optimizer. Because every binding points to one library, the object identity of a quantum program survives the language boundary.
Why Fortran, C++, and Julia? They are the languages where the compute-heavy cores of physics, chemistry, and engineering simulation code are typically written, and where the high-performance computing community carries its real science. Python is widely used as orchestration in those workflows, but the heavy lifting runs in compiled code that has been refined and tested for decades. Forcing quantum access through Python meant that groups maintaining large Fortran or C++ codebases had to either rewrite in Python or build and maintain their own translation layer. The v2.0 bindings collapse that requirement.
The C API is the lever. By exposing the Rust core through C, the lowest-common-denominator foreign function interface that every compiled language can call, IBM turned Qiskit's internal representation into a portable artifact. The bindings for Fortran, C++, and Julia are thin wrappers around that interface, which means updates to the core propagate to every frontend without a separate implementation.
IBM is positioning this as the foundation for hybrid quantum-classical workflows in optimization, machine learning, and scientific simulation. The realistic first users are researchers and engineers with existing HPC code who want to drop a quantum subroutine into a routine they have already spent years tuning, rather than port their domain knowledge into a new stack.
The interoperability and HPC-integration claims are vendor-stated in a single IBM Research blog post. The source excerpt available at the time of this draft is partial, and Qiskit's release notes for v2.0 have not yet been cross-checked against an independent repository or community write-up. Other major quantum SDKs, Cirq, PennyLane, and the Braket SDK, remain Python-first, so the architectural pattern Qiskit is showing off is one product release ahead of any category-level shift.
The next thing to watch is whether the C API is treated as a public, stable interface for outside contributors, or whether the binding surface moves with each minor release. The shared library makes the architecture durable; binding stability is what would let Fortran and C++ teams build on it without fear of breakage.