First, I’m glad to see some effort on this, there should indeed be some discussion on how to make Julia quantum packages more composable. I’d like to share a few related issues under Yao:
take on the general quantum community in Julia is that it lacks overall cohesion; it’s just a bunch of people writing Julia code for their own quantum projects. My point, however, is that Julia would benefit from an ecosystem of integratable tools for quantum applications. This requires collaboration and cohesion across packages in the Julia Quantum problem space which is simply, the joy of open-source software
However, as a former member of JuliaQuantum, and as the author of quite a few packages under QuantumBFS, I learned a lot of lessons from the failure of JuliaQuantum, JuliaQuantum/QuBase etc.
It’s always good to make an
XBase package to solve the name ownership problem, but not the opposite, this is because high-level abstraction needs enough concrete use cases to support. E.g
YaoBase is born from the effort of reducing the package size of Yao and make certain interface functions reusable, it is not created in the first place. This is the same for other well-known packages like
XBase packages should be common code that is moved out from other concrete projects, not the other around.
The failure of JuliaQuantum is mainly because it didn’t start from anything concrete - that is solving a specific problem, it was trying to set a rule, a set of abstractions to follow (e.g start from Base packages, more roadmaps, and code of conduct than code) for people who want to solve problems, which actually creates obstacles for creating new functionalities.
but it looks pretty dead to me
I have removed it from the official website, but haven’t got time to update the website to point to other organizations.
The other lesson I learn from the failure of QuBase is avoiding over-abstraction, writing generic code is good, but not always, especially in a lot of cases it can be hard to write generic code - implementing a top performance simulator for qubit basis just for a single thread CPU is extremely easy (you can do this in one day), but implementing a top performance simulator for arbitrary basis is extremely hard.
In summary, I think it would be much more convincing to show if QBase can actually make Yao, QuantumOptics, and QuantumInformation work together seamlessly, which actually solves a problem than just implementing similar things in an entirely new setup in order to make QBase be “the Base package” for Julia quantum packages.
I hope this helps.