IBM has expanded Qiskit’s entry points beyond Python by enabling its use from Fortran, C++, and Julia through a unified C interface that reaches the high-performance core written in Rust. The company says this design allows quantum circuits to be built and run directly within existing applications, without embedding a Python interpreter or transferring data into Python objects.
The move has been available since Qiskit 2.0, which introduced the C interface for the development package’s underlying data model. Because the three language bindings use the same shared Qiskit library, circuits created in one language can, in principle, be passed to another language such as C++ and Fortran while retaining the same object.
Three Paths to Qiskit
For Fortran, IBM provides the qiskit-fortran interface for building and handling circuits, using the standard iso_c_binding mechanism to call the C interface. The circuit uses a derived type that frees memory when the variable leaves scope. Data such as a Hamiltonian can also be passed directly from quantum chemistry applications already residing in Fortran memory to circuit-building procedures, without copying it into Python or reallocating it.
As for qiskit-cpp, which IBM first announced the previous year, it is a C++ interface that works through header files only. A program can be linked to the Qiskit C library, while the circuit object’s memory is managed automatically when it leaves scope. IBM mentions the possibility of sending circuits through the C client for qiskit-ibm-runtime or through QRMI and SQC.
Qiskit.jl and QiskitIBMRuntime.jl provide an interactive path for Julia users, including work inside Jupyter notebooks and access to IBM Quantum hardware. The two packages hide the details of C pointers and also enable circuits to be created and run in a style close to Qiskit in Python, while accounting for the fact that Julia starts qubit numbering at 1 whereas Python uses numbering from 0.
What Changes in Practice?
The new interfaces target researchers whose scientific applications rely on Fortran, C++, or Julia, particularly in simulation, physics, chemistry, engineering, and high-performance computing. Instead of running Qiskit as a separate process or using Python to coordinate every step, the quantum circuit can be called as a linked procedure within the classical application itself. This includes building the circuit, optimizing it for specific hardware, sending it to the hardware, and then processing the results.
IBM demonstrates this path through a Julia example simulating a transverse-field Ising model on a system of up to 100 qubits. The example includes approximating the evolution of the Schrödinger equation using Trotterization, then optimizing the circuit, running it on hardware, and calculating site magnetization. The example’s conceptual results show that reducing the Trotter step size lowers approximation error but increases circuit depth, which may ultimately produce more hardware noise than the gain resulting from increased accuracy.
Limitations and Open Questions
IBM emphasizes that all non-Python bindings are still under active development, so the announcement does not present final stable interfaces or detailed comparative performance results. The 100-qubit example also does not mean that the practical limitations of quantum computing have been overcome; the classical tensor-network simulation reference becomes less reliable as entanglement increases, while execution accuracy remains tied to Trotter error and hardware noise.
The core value here is reducing software friction in integrating quantum resources into existing HPC code, not providing new quantum capabilities in itself. The impact of the interfaces will depend on the maturity of the packages, their integration with current research environments, and the ability of quantum hardware to deliver results beyond what classical alternatives provide.