3 ms·

> 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/microsof

by hu3 3y ago

> 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 https://github.com/microsoft/qsharp/tree/main/wasm

ilc 3y ago
Maybe WASM is going to finally deliver the dream of the JVM, and CLR. Maybe.
- pjmlp 3y ago
  Or P-Code, M-Code, TIMI,...
FrustratedMonky 3y ago
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#?
- hu3 3y ago
  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/wasm https://vercel.com/docs/concepts/functions/edge-functions/wa... It also has some interesting isolation properties.
  - syrusakbary 3y ago
    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 https://wasmer.io/products/edge
    - hu3 3y ago
      I respect the hustle. Sorry for not mentioning https://wasmer.io https://wasmer.io. Keep it up! Competition is great.
    - kentonv 3y ago
      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.)
      - syrusakbary 3y ago
        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!
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.
Zambyte 3y ago
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?

by hu3 3y ago

ilc 3y ago

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

pjmlp 3y ago
Or P-Code, M-Code, TIMI,...

FrustratedMonky 3y ago

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#?

hu3 3y ago
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/wasm https://vercel.com/docs/concepts/functions/edge-functions/wa... It also has some interesting isolation properties.
- syrusakbary 3y ago
  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 https://wasmer.io/products/edge
  - hu3 3y ago
    I respect the hustle. Sorry for not mentioning https://wasmer.io https://wasmer.io. Keep it up! Competition is great.
  - kentonv 3y ago
    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.)
    - syrusakbary 3y ago
      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!

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.

Zambyte 3y ago

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?