qsharp-compiler VS qsharp

It was previously written in C# and F#: https://github.com/microsoft/qsharp-compiler

These are starting to get developed, for example Microsoft's Q#

(disclaimer: I work on the team developing Q# and its tooling)

That's part of the goal of Q#. It's designed to be a language which allows you to build up from quantum gates, efficiently work with quantum concepts such as 'adjoint' and 'controlled' operations, and build that up into a higher level of abstraction. You can see an old post as to some of the reasoning when it was first developed at <https://devblogs.microsoft.com/qsharp/why-do-we-need-q/>.

Another consideration to some of the points raised here, is that even on today's state-of-the-art hardware you typically only get a couple thousand gates at best before noise overwhelms the system and the qubits 'decohere' (https://en.wikipedia.org/wiki/Quantum_decoherence). So you do often want to develop at a level where you can squeeze every last gate out of whatever program you're writing. (If you intend to run it on a quantum computer and not just simulations).

Being that the post is about quantum simulation, you can see the one our team built in Rust at https://github.com/qir-alliance/qir-runner/blob/main/sparses... . This uses 'sparse' simulation, which means any state with a probability of 0 isn't tracked, which turns out to be quite a few in a lot of algorithms. This allows you to simulate many more qubits than you can with a full state simulator (where you need to track 2^n states for n qubits). It also does some other nifty tricks where you can elide or combine gates before they are performed to get even more perf. We use it in our new Q# stack (https://github.com/microsoft/qsharp) to run program simulations in our CLI or in the browser (such as on our new https://quantum.microsoft.com site), or inside VS Code (desktop or web)).

We are looking to evolve the Q# language and improve the quantum development experience, with a focus given to a 'scalable' quantum future where gate count and noise is less of a limit, and moving development higher up in abstraction - as you outline. So if it is something you have an interest in, we're more than happy to get the input on the qsharp GitHub repo linked to above.

Portability, minimal size, and speed are all priorities. Building with Rust allowed us to really focus on all of these for both WebAssembly and OS binaries.

For example, if you go to the playground that we publish on every push to main (https://microsoft.github.io/qsharp/), and open the Developer Tools to see the network traffic, you'll see that our WebAssembly module is just 1.5MB (504kb over the wire) - which includes the not just the language (parser, type system, IR, etc.) but also the runtime interpreter and quantum simulator.

Similarly, for the native tools, on my MacBook (i.e. ARM64) the command line compiler ("./target/release/qsc") is 3.9MB, which is entirely standalone with no dependencies.

We do have many features to add, so I'm sure those will grow a bit, but we are focused on keeping things as small, portable, and fast as a general principal.