4 ms·

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

by billti 3y ago

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!

nightski 3y ago
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.
- phillipcarter 3y ago
  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.
  - pjmlp 3y ago
    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.
FrustratedMonky 3y ago
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.
- billti 3y ago
  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/ 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.
  - pjmlp 3y ago
    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.
  - FrustratedMonky 3y ago
    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#.
gavinray 3y ago
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 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/wasm/browser-advanced/Program.cs https://github.com/dotnet/runtime/blob/main/src/mono/sample/...
- moonchrome 3y ago
  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.
  - pjmlp 3y ago
    Ever heard of Flash? Or for something more modern, Flutter.
    - moonchrome 3y ago
      Flash was abandoned because it was horrible. Flutter is basically cost center app framework (like xamarin) - not something you model performant software after.
      - pjmlp 3y ago
        Flash was abandoned because Apple said so. Flutter is doing quite alright, much better than Xamarin, with the MAUI reboot.

by billti 3y ago

nightski 3y ago

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.

phillipcarter 3y ago
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.
- pjmlp 3y ago
  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.

FrustratedMonky 3y ago

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.

billti 3y ago
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/ 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.
- pjmlp 3y ago
  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.
- FrustratedMonky 3y ago
  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#.

gavinray 3y ago

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 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/wasm/browser-advanced/Program.cs https://github.com/dotnet/runtime/blob/main/src/mono/sample/...

moonchrome 3y ago
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.
- pjmlp 3y ago
  Ever heard of Flash? Or for something more modern, Flutter.
  - moonchrome 3y ago
    Flash was abandoned because it was horrible. Flutter is basically cost center app framework (like xamarin) - not something you model performant software after.
    - pjmlp 3y ago
      Flash was abandoned because Apple said so. Flutter is doing quite alright, much better than Xamarin, with the MAUI reboot.