Thank you once again for writing such an excellent article <3
In contrast to some other comments here, I love the narrative style. After all, these are half tutorials half entertainment - and the entertainment keeps it enticing. I would not have spent nearly two hours reading about the nitty-gritty of futures implementation details today if it weren't for the way you write about things.
To put it the other way - if I wanted to read a super condensed, concise reference of how these things work, I would, you know, read a reference. The narrative style of building things on your own, solving problems as you face them, picking tools and libraries on the way, feels relatable as the everyday lived experience of software development. It feels appropriate for the medium - it's a blog after all!
Besides, blogs are the perfect place to mention the tiny useful tools and libraries people might not have heard of. References and books might err on the side of being "neutral" and not making opinionated recommendations, but this can also lead to unknown unknowns. People don't know what they are missing out on! Luckily, blogs have more freedom here. Mentioning things like `cargo-edit`, `serde` and others can probably make some readers feel like "one of today's lucky ten thousand" - enjoying the newly-gained quality of life improvements.
Yeah! This article not just explains how async works, the author show research methods to learn how async works. How something works is transient knowledge, how to learn how something works is timeless priceless knowledge.
The methods include strategically inserted panic!, some nice crates with examples how to use them... I cannot say I've learnt a lot about async, but I got few insights on technicalities of self-learning.
Thank you all for the feedback! I'll continue to make improvements to this post, as well as build more in the next parts.
My current understanding is mostly based on this wonderful website: https://quantum.country/qcvc - if you can recommend more good resources, I'm all ears!
Thank you for feedback! Going to read the paper to improve my understanding. I'm writing this blog series in part to learn more - both about quantum computing as well as Rust. As some people say, teaching is a great way to learn (or at least check your knowledge).
What do you think would be a good correction or disclaimer to add? Would it be sufficient to e.g. say that in this first part, we only implement a two-component ket? Generalizing the ket type to an arbitrary-size vector while keeping type constraints, perhaps briefly mentioning const generics (an upcoming language feature), etc could easily make for another part in this series. Making the ket into an actual vector could then give way to doing proper linear algebra on them, cleaning up some of the manually implemented operations here, as their teaching purpose has been fulfilled already.
I would say you’ve implemented a state vector for a single qubit (when the norm = 1 and when equality is defined to be phase invariant, i.e., x and y are equal whenever there’s an ‘a’ such that e^(ia)x = y.), which can be written down notationally with a ket:
|s> = p|0> + q|1>
where p and q are complex, and |p|^2 + |q|^2 = 1. The ket is the notation |s>, |1>, and |0>, which could also be written purely as column vectors.
At the end it all depends on what you want to present. What will be the climax? Unitary evolution of a pure state? Superoperators on a mixed state? An introduction to linear algebra used in quantum computation and its notation?
In any case I’d present what a quantum state is on N qubits, which requires 2^N-element complex vectors that satisfy a few properties.
Having "quantum computing" in the title makes this genuine clickbait when the body lacks any explanation of what a state is or what a ket is. Energy or momentum or spin states are rarely (never, in reality) just numbers.
You made no attempt to explain what the two different states in a single ket mean: hint, it's superposition. Never provided even a trivial justification for why normalization is important; where is the actual physics?
Using Rust here is also quite pointless when you're just doing linear algebra... where is the actual benefit over Python or even Haskell?
You've written a very cute and inefficient math library, but calling this QC is just false advertising.
You're right, the essay needs a better explanation on what a ket and a quantum state is. I'll figure something out.
Excellent point with the superposition, I'll add that in! Same with the normalization - while adding the `is_valid` method to the struct makes sense programming story -wise, it'd be great to justify its origins and implications.
As for using Rust being pointless - I am writing this blog post series for three reasons: learning more Rust by doing, learning more quantum computing by doing, and sharing my journey as a tutorial. Using Rust for the sake of learning (and hopefully helping others learn) Rust is in my opinion a perfect reason to use Rust.
As for calling this QC - I'd clarify that this code does not intend to be a production-grade QC library, and the blog post series does not intend to be an exact, axioms-and-proofs type of an university level course that prepares you for the industry in one go. I'd think of it more as a Todo MVC app building journey with a quantum flavor - or something. That being said, I do plan to add more QC features in the next posts of the series, and incrementally add to the accuracy as much as I feasibly can. All this feedback here and links to more materials are helping me immensely, I want to learn more about this stuff!
Thank you for calling it very cute - I really appreciate that! ️
In contrast to some other comments here, I love the narrative style. After all, these are half tutorials half entertainment - and the entertainment keeps it enticing. I would not have spent nearly two hours reading about the nitty-gritty of futures implementation details today if it weren't for the way you write about things.
To put it the other way - if I wanted to read a super condensed, concise reference of how these things work, I would, you know, read a reference. The narrative style of building things on your own, solving problems as you face them, picking tools and libraries on the way, feels relatable as the everyday lived experience of software development. It feels appropriate for the medium - it's a blog after all!
Besides, blogs are the perfect place to mention the tiny useful tools and libraries people might not have heard of. References and books might err on the side of being "neutral" and not making opinionated recommendations, but this can also lead to unknown unknowns. People don't know what they are missing out on! Luckily, blogs have more freedom here. Mentioning things like `cargo-edit`, `serde` and others can probably make some readers feel like "one of today's lucky ten thousand" - enjoying the newly-gained quality of life improvements.