This is super exciting for me, as a C# developer. I'm fed up of needing (to learn how) to compile C++ projects for each platform so that I can reference them from .NET Core. The idea of just compiling them once for WebAssembly/WASI and only needing to ship one copy of each binary dependency is quite freeing and makes cross plat functionality easier.
There's a bunch of language extensions which let you access C# heap, string types etc from C++. You may want to define a "shim" layer to do the translation, but the bulk of your existing C++ can just compile straight across.
I think this is about c++-in-wasm-in-C# rather than c#-in-wasm. It's an (arguably) better way of doing FFI without having to worry about compiling the C++ dependency.
Right, some libraries are already getting official and semi-official wasm targets for the Node JS ecosystem. It would be interesting to "borrow" an existing wasm binary from npm and simply rehost it on the .NET CLR or JVM.
Yep. One of my all-time favorite blog posts anywhere is his 2003 post "The .NET Abstraction Pile", where he lists 40-some different abstraction layers involved in clicking the "Check In" button in a networked version control system:
This reminds me of the early days of .NET when COM objects could be used with a shim that allowed .NET applications to consume existing COM components... but the lifecycle and memory management of those objects were beyond the ability of .NET to control and an error in the COM object could still crash your .NET app even though the loading and unloading of the COM component was wrapped in a try/catch... such frightful memories! I'm curious how the GC/exception handling story will be different by going through WASM to MSIL as opposed to the days prior to framework 2.0 and COM components.
yeah, assuming that I've not got the wrong end of the stick, you could still have all the usual C/C++ issues take down your process. Although, seriously...pinvoke and the like are a PAIN. This is really interesting. Cheers.
There's a bunch of language extensions which let you access C# heap, string types etc from C++. You may want to define a "shim" layer to do the translation, but the bulk of your existing C++ can just compile straight across.
[1]: https://github.com/dotnet/coreclr/issues/18013
-> https://ericsink.com/tocs/topics.html
https://ericsink.com/Abstraction_Pile.html
A particularly good quote:
> I stop whenever I get to Physics or Chemistry. For my purposes, light is real, not an abstraction.
> Whatever you call it, what this project does is take a WebAssembly module and convert it into a .NET assembly on disk.
So running such code should be no different than any other .Net code in that regard.
As such I don't see how it wouldn't play nice, unlike PInvoke/COM stuff, which is native code doing whatever native code feels like.
I wonder thought if one could just build CIL backend for LLVM.