Hacker News Reader

Comment by FrustratedMonky | Hacker News Reader

So sad. Love F#, and Q# seemed like a natural extension, or at least brotherly.

At a high level, it seemed like F# is more functional like OCaml, than Rust is. I'd like to hear more about the reasoning, was it just performance? How different was it to justify a re-write?

View on HN

> I'd like to hear more about the reasoning

My guess is because Rust is great with WebAssembly and they seem to target it with Q#:

https://github.com/microsoft/qsharp/tree/main/wasm

Well, wasm runs slower right? I'm not that familiar. Seems that if wasm is a goal, then that might negate they did this for performance. What other benefit is there to wasm that would make it a fit for Q#?

Slower than native perhaps. But usually faster than JavaScript on V8.

So if you want fast browser perf, Wasm is a great choice.

There's also Wasm on the edge with the likes of Cloudflare Workers and Vercel https://vercel.com/docs/concepts/functions/edge-functions/wa...

It also has some interesting isolation properties.

Shameless plug for WebAssembly on the Edge: Wasmer recently launched Wasmer Edge, which is Wasm-focused instead of JS-focused compared to Cloudflare Workers and Vercel

https://wasmer.io/products/edge

I respect the hustle. Sorry for not mentioning https://wasmer.io. Keep it up! Competition is great.

When this site says Wasmer's "cold start time" is 50ns, what is it measuring?

You can't even do a syscall in 50ns.

Cloudflare's 5ms includes time to read the application code from disk. (I'm the one who originally did this measurement.)

Hi Kenton!

50ns is the median time to initialize the Wasm module. I think it would make sense to do another round of measuring with more factors that test things end to end, and see how each of the platform performs.

BTW, I'm a big admirer of Cloudflare Workers... great work!

Maybe WASM is going to finally deliver the dream of the JVM, and CLR.

Maybe.

Or P-Code, M-Code, TIMI,...

Disclaimer: engineering manager for the team building it

Yes, targeting WebAssembly, and the ability to then run in the browser, was a big part of it.

WebAssembly (will) also enable our language service extension to run in VS Code for the Web, as well as VS Code for desktop, with largely the same feature set.

It also means the core logic compiles to very performant native code for most platforms, which we use for the CLI.

It's early days for the project, with lots of work ahead of us, but I'm really proud of this first step. Happy to answer any other questions where I can!

Interesting and disappointing that someone from Microsoft would convey that .NET Core is too slow and not portable enough :) VS Code is Microsoft's tool after all.

It's true though. I mean, not a knock on the .NET team. They (we in a past life!) have moved mountains to get a crusty old Windows desktop development framework into the modern era. But all this does is highlight that the work isn't done yet.

Looking at how others haved approached this kind of stuff, meaning AOT compiled managed languages, like on Google and Apple platforms, and the ups and downs of .NET in Windows desktop development since 2001, from the outside it always feels like the usual set of WinDev vs DevDiv politics.

Isn't one of the benefits of F# the ability to compile into other languages. I'd think it would be possible to have F# run on WebAssembly. But, guess I'm too focused on F#, this is really about Q# running on web assembly, so maybe writing Q# in F# and F# being able to generate web assembly, is too many layers? Added complication?

So, am I hearing correctly, the goal was really about portability, and allowing Q# to run in a browser, not for any performance reasons of .NET.

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.

In a way this seems to acknowledge Native AOT isn't ready and it was better to spend development effort for a full rewrite than collaborating with .NET team to improve the pain points.

Re-reading all the posts. I do come back to a basic question, or something I don't get. (and I haven't kept up with WASM, sorry).

If Q# is a language for quantum computing, and it is a niche language just for exploring quantum computing.

Then, how does that lead to a requirement to re-write to target WASM?

If you are a person that would be doing quantum computing, why do you care if you can run it in a web browser, or VS code for the web. You would just install tooling on your own machine. Or if you are editing code in a web browser, the code itself would get compiled and run on server, why does it have to compile and run right there in a browser.

So if we remove WebAssembly as a goal, Why can't you just use .NET, CLR and stick with current MS languages to build it in?

I don't understand why running in the web is a needed feature for this set of users.

I understand RUST is very speedy. Is that the real goal, and all of "Rust also works on WASM", is just a side benefit?

Seems like quantum computing needs speed. Performance is the real goal. To simulate a quantum computer a normal computer must run many more steps.

So we have performance of : .NET, Rust binary, or Rust to WASM.

Guess, maybe I answered my own question. If Rust is faster then .NET, then that is goal, and Rust can also run on WASM as option is a side benefit.

I'm afraid this seems to be more indictment of .NET in general, not just F#.

But C# has the ability to compile to WASM and run in the browser, using the Mono WASM runtime that's part of the .NET core repo now.

This is what underpins Blazor.

https://github.com/dotnet/runtime/tree/main/src/mono/wasm

Example C# app running in a browser:

https://github.com/dotnet/runtime/blob/main/src/mono/sample/...

You can technically use nail clippers to mow your lawn as well.

Deploying GC language with a huge runtime and stdlib to WASM sounds like a bad idea.

Ever heard of Flash?

Or for something more modern, Flutter.

Flash was abandoned because it was horrible.

Flutter is basically cost center app framework (like xamarin) - not something you model performant software after.

Flash was abandoned because Apple said so.

Flutter is doing quite alright, much better than Xamarin, with the MAUI reboot.

But the language that the compiler is written in doesn't really relate to the target system (ie WASM). Unless they're planning in running the Q# compiler itself in a WASM environment. Which in that case... why?

Reply on news.ycombinator.com