QuBitLang vs Qiskit: Why We Built a Quantum Language Instead of Using IBM's SDK

Qiskit is the most widely used quantum computing SDK in the world. It's open source, backed by IBM, and used by thousands of researchers and developers. So why did we build QuBitLang — a completely new quantum programming language — instead of just using Qiskit directly? This article is an honest, technical comparison of both approaches.

What Qiskit Is

Qiskit is IBM's open-source quantum computing SDK, written in Python. It provides tools for building quantum circuits, simulating them locally, transpiling them to native hardware gates, and executing them on IBM Quantum processors. It's mature, well-documented, and the standard tool for quantum computing research.

Qiskit is a library, not a language. You write Python code that calls Qiskit's API to construct circuit objects. A simple 2-qubit Bell state circuit in Qiskit looks like this:

This is clean and compact. For a two-qubit circuit, the Qiskit version is perfectly fine. The friction appears when circuits get larger, when you need compile-time safety guarantees, or when you want to describe quantum logic without Python's boilerplate.

What QuBitLang Is

QuBitLang is a purpose-built quantum programming language with its own syntax, compiler, type system, and execution pipeline. It's not a wrapper, not a transpiler, and not a DSL embedded in Python. It's a standalone language that compiles .ql source files through a 7-stage compiler pipeline into optimised Qiskit circuits for execution on IBM Quantum hardware.

The same Bell state in QuBitLang:

No imports. No object construction. No classical register allocation. The syntax reflects the quantum logic directly: declare qubits, apply gates, measure. The compiler handles everything else.

The Comparison

This isn't a competition — Qiskit and QuBitLang serve different purposes. Qiskit is a general-purpose quantum computing toolkit for research and exploration. QuBitLang is a domain-specific language optimised for production quantum entropy generation. Here's how they compare across the dimensions that matter for our use case.

1. Abstraction Level

Qiskit operates at the circuit construction level. You build circuits by calling methods on Python objects: qc.h(0), qc.cx(0, 1), qc.measure(). The quantum logic is expressed through Python's general-purpose syntax. This is flexible — you can use Python's full power for classical control flow, parameterisation, and data processing — but it means the quantum structure is embedded in, and sometimes obscured by, Python code.

QuBitLang operates at the quantum logic level. Qubits are first-class citizens declared with QUBIT. Gates are applied with function-call syntax: H(q0), CNOT(q0, q1). Measurement uses an explicit arrow: MEASURE q0 -> c0. You can read a QuBitLang circuit and understand the quantum structure at a glance, without parsing Python semantics.

2. Compile-Time Safety

Qiskit performs minimal validation at circuit construction time. You can measure a qubit twice, apply a gate to an undeclared qubit (via integer index), or create type mismatches — and you won't know until the circuit fails at transpilation or execution. Qiskit's runtime errors are Python exceptions, which means they surface late and can be cryptic.

QuBitLang has a full semantic analyser that catches errors at compile time: double-measurement of a qubit, operations on undeclared qubits, type mismatches between quantum and classical values, and scope violations. If your .ql file compiles, the circuit is structurally valid. This matters because quantum hardware time is expensive — a failed circuit on a QPU wastes queue time and money.

3. Hardware Portability

Qiskit is IBM-specific by default. While it can target other backends via third-party providers, the SDK, transpilation pipeline, and runtime are optimised for IBM Quantum hardware. Switching to Quantinuum or Rigetti requires different SDKs (pytket, pyQuil) with different APIs.

QuBitLang uses a hardware-agnostic intermediate representation. The compiler's IR sits between the language and the backend — today the code generator targets Qiskit/IBM, but adding a Quantinuum or Rigetti backend requires only a new code generator module. The same .ql source runs on any backend without modification. Learn more on our features page.

4. Optimisation

Qiskit has a mature transpilation pipeline with multiple optimisation levels. It handles gate decomposition, routing, and scheduling for specific hardware topologies. This is a strength — Qiskit's transpiler is battle-tested and handles hardware-specific constraints that QuBitLang doesn't need to worry about.

QuBitLang applies circuit-level optimisations at the IR stage: gate cancellation (adjacent inverse gates), rotation merging, and redundant operation removal. These reduce circuit depth before the circuit reaches Qiskit's transpiler. The result is a two-stage optimisation: QuBitLang optimises the logical circuit, then Qiskit optimises the physical mapping. Both stages improve fidelity on noisy hardware.

5. Ecosystem

Qiskit has a massive ecosystem: Qiskit Nature (chemistry), Qiskit Machine Learning, Qiskit Finance, Qiskit Aer (simulation), extensive tutorials, an active community, and IBM's full documentation. If you're doing quantum research, Qiskit is the obvious starting point.

QuBitLang has a focused ecosystem: the compiler, the StateVector simulator, and the TrueEntropy production pipeline. It's not trying to be a general-purpose quantum toolkit. It's designed to do one thing exceptionally well: define, compile, optimise, and execute quantum circuits for entropy generation. The documentation reflects this focus.

Side-by-Side: QRNG Circuit

Here's the actual production QRNG circuit used by TrueEntropy, shown in both languages. This is the circuit that generates every quantum random number we deliver.

For this simple circuit, the code length is similar. The difference isn't about brevity — it's about what happens after you write the code. In Qiskit, you need to add transpilation, backend selection, job submission, result extraction, and bitstring processing — all in Python. In QuBitLang, the compiler pipeline handles all of that. The .ql file is the only source file you write.

Where Qiskit Wins

We're not going to pretend QuBitLang is better at everything. Qiskit has clear advantages:

• General-purpose quantum computing — If you're building quantum algorithms for chemistry, optimisation, or machine learning, Qiskit's ecosystem is unmatched
• Community and support — Thousands of contributors, IBM backing, extensive tutorials, Stack Overflow presence
• Flexibility — Python's full power is available for classical pre/post-processing, parameterised circuits, and dynamic circuit construction
• Qiskit Runtime — Session management, error mitigation, and primitives (Sampler, Estimator) for advanced workloads
• Visualisation — Circuit diagrams, Bloch spheres, state visualisation built in

If you're a quantum researcher exploring new algorithms, Qiskit is the right tool. We use Qiskit ourselves — it's the backend that QuBitLang compiles to.

Where QuBitLang Wins

QuBitLang's advantages are specific to the production quantum entropy use case:

• Compile-time safety — Catch errors before they reach expensive quantum hardware
• Human-readable circuits — The source code reads like the quantum logic it describes
• Hardware abstraction — One source file targets any backend, today and in the future
• Provenance — Every API response includes the QuBitLang circuit name and version, creating a verifiable chain from source code to random number
• Intellectual property — A proprietary language is a competitive moat that no competitor can replicate by installing a package
• Two-stage optimisation — QuBitLang optimises the logical circuit; Qiskit optimises the physical mapping

Why Not Just Use Qiskit?

The real question isn't "which is better?" — it's "why build a language at all?"

We could have built TrueEntropy using Qiskit directly. The QRNG circuit is simple: 8 Hadamard gates and 8 measurements. The Qiskit code would be a few lines. So why invest in a compiler, a type system, a semantic analyser, and an optimiser?

Three reasons:

1. Provenance and trust. TrueEntropy serves regulated industries — gambling, cryptography, clinical research. These customers need to know exactly what circuit produced their random numbers. A named, versioned QuBitLang circuit (qrng_hadamard_v2.3) is a cleaner provenance record than "some Python script that calls Qiskit." The circuit source can be independently reviewed, and the circuit name appears in every API response.

2. Competitive moat. Any company can install Qiskit and build a QRNG. Very few companies can build their own quantum programming language. QuBitLang is a genuine technical differentiator — not a marketing claim, but a real compiler with real source files, real optimisation passes, and a real type system. Read the story of how it was built.

3. Future-proofing. When we add support for Quantinuum or Rigetti hardware, we write a new code generator — not new application code. When we add new circuit types (GHZ states, Bell pair entanglement), we write .ql files — not Python scripts. The language is the abstraction that makes the rest of the system stable.

The Summary Table

The Honest Answer

QuBitLang and Qiskit aren't competitors. QuBitLang uses Qiskit — it compiles to Qiskit circuits, which are transpiled and executed on IBM Quantum hardware via Qiskit Runtime. Qiskit is the backend; QuBitLang is the frontend.

The decision to build a language was a bet on the importance of abstraction, provenance, and competitive differentiation. For a production quantum entropy service serving regulated industries, those properties are worth the engineering investment. For a research lab exploring new quantum algorithms, Qiskit's flexibility and ecosystem are more valuable.

Both are valid choices. We made ours, and it powers every random number TrueEntropy delivers.