fp-course VS qsharp

The tooling around F# is very lacklustre, I wish it had better support from MS.

As for learning a functional language, I recommend this Haskell tutorial[0], and accompanying video series of an experienced haskeller running through it[1]. I've read countless texts and tutorials explaining Haskell and FP to me but it didn't fully click until I saw someone with experience using the language and tooling effectively.

[0]: https://github.com/system-f/fp-course

If your goal is to learn parser combinators (as opposed to just attoparsec), you should really consider doing the parser module of the Nicta FP course.

Seconding "Haskell Programming From First Principles". There's also the FP course with lots of exercises on common Haskell abstractions: https://github.com/system-f/fp-course

Intro course: https://github.com/system-f/fp-course

Also, when teaching the NICTA/Data61/System-F FP course, one of the first things you will learn is all functions take exactly one argument, and this is always true, there are no exceptions. Internalising this will help you a lot when you start to playing with things like Applicative and Monads (which you will, soon, and eventually realise you already use all the time in the other languages you use)

Pretty cool. They note that they are inspired by Go by Example [0] and Rust by Example [1], and this book seems stylistically similar to the community-driven Learn X in Y minutes site [2] which covers quick syntax/conceptual overviews for many other languages as well.

Looks like typeclasses.com offers a few more advanced Haskell courses for a $29 USD/month subscription. For the same target audience looking for free coursework/exercises, I'd recommend working through the Data61 Haskell course [3]. Brian McKenna has a nice Youtube series [4] covering it.

[0] https://gobyexample.com/

[1] https://doc.rust-lang.org/rust-by-example/index.html

[2] https://learnxinyminutes.com/

[3] https://github.com/system-f/fp-course#readme

[4] https://www.youtube.com/watch?v=NzIZzvbplSM

Not a project exactly, but a series of exercises that lead to couple of projects: https://github.com/system-f/fp-course. Let me know what you think.

(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.