WASI support tracking

[SteveSandersonMS]

Description

This issue is to track known issues in the early WASI-enabled runtime builds. These need to be resolved in order to have a proper supportable WASI-ready release.

• Add wasi-wasm RID
  • [wasi] Add new RID for WASI #77780
  • [API Proposal]: OperatingSystem.IsWasi() #78389 API change
• Build System.Native using WASI SDK instead of using the Emscripten-built binary.
  • MSbuild files for it and generate wasm_m2n_invoke.g.h
  • Enable p/invokes to all APIs exposed by System.Native. Currently there's a small hardcoded list.
  • [wasi] compile with libs.native #79046
• Create nuget package for WASI-SDK (dotnet/wasi-sdk)
  • Enable workload use of dotnet/wasi-sdk packages #95086
• Add WASI runtime as XHarness target
  • Add the WASI runtime test target xharness#977
• Enable GC finalizers. Currently the finalizer thread isn't started (see mono_gc_finalize_notify in gc.c).
  • fix stack range WASI gc - fix stack range #80456
• Support .NET threads on threading-enabled wasm runtimes. This includes updating the synthetic-pthread.c code to support having separate pthread keys for each thread instead of a single global list.
• [mono][wasi] Fix ALC support, See the WASI comment in ves_icall_System_Reflection_Assembly_InternalLoad. #95137
• create ICU transport package and use it
• Added wasi-sdk flow icu#307
• Add wasi-wasm in icu package icu#309
• Icu wasi package #81345
• make it work on wasmedge Get issue while running with Wasmedge dotnet-wasi-sdk#5 Wasm build hangs when using WasmEdge #85429
• make it work on wasmer How to run web app with wasmer dotnet-wasi-sdk#6
• create WASM module import from any [DLLImport] which doesn't match known static native symbols #86984
• maybe create WASM module export from [UnmanagedCallersOnly] #86985
• do we need vitual file system ? [wasi] do we need VFS #81418
• [mono][wasi] WASI size improvements #94803
• Mono AOT Support
  • [wasi] Initial wasi/aot build support #95051
  • Add a optional AOT mode on wasm which doesn't depend on c++ unwinding so … #95074
  • [mono][wasi] Stand up AOT tests in ci #95136

Build

• Have a real CI build (including some test) and a public distribution mechanism.
  • [mono][wasi] Add a CI lane for a new wasi RID #72641
  • [wasm] wasi: Enable library tests on CI #81052
• Produce binaries into experimental workload , in similar way as we do for multi-threading WASM ([wasi] Add wasi-experimental workload, wasiconsole template, and Wasi.Build.Tests #81849)
• wasi templates ([wasi] Add wasi-experimental workload, wasiconsole template, and Wasi.Build.Tests #81849)
• WasmAppHost support ([wasi] Add wasi-experimental workload, wasiconsole template, and Wasi.Build.Tests #81849)
• wasi.build.tests ([wasi] Add wasi-experimental workload, wasiconsole template, and Wasi.Build.Tests #81849)
• App builder, merged targets etc ([wasi] Add wasi-experimental workload, wasiconsole template, and Wasi.Build.Tests #81849)

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

This issue is to track known issues in the early WASI-enabled runtime builds. These need to be resolved in order to have a proper supportable WASI-ready release.

• Support .NET threads on threading-enabled wasm runtimes. This includes updating the synthetic-pthread.c code to support having separate pthread keys for each thread instead of a single global list.
• Enable GC finalizers. Currently the finalizer thread isn't started (see mono_gc_finalize_notify in gc.c).
• Enable p/invokes to all APIs exposed by System.Native. Currently there's a small hardcoded list.
• Build System.Native using WASI SDK instead of using the Emscripten-built binary.
• Fix ALC support, which in turn probably means fixing something about stack walking. See the WASI comment in ves_icall_System_Reflection_Assembly_InternalLoad.

Reproduction Steps

Expected behavior

Actual behavior

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Author:	SteveSandersonMS
Assignees:	-
Labels:	arch-wasm, area-Build-mono
Milestone:	-

[mhmd-azeez]

Is exporting functions to wasi tracked here too?

[pavelsavara]

Is exporting functions to wasi tracked here too?

Added

[mhmd-azeez]

@pavelsavara Thanks! We also need the opposite: Exporting functions so that you can create a .NET library and compile it to wasm and consume it from the other languages. It's already possible from Go, C, C++, and Rust. See this sample: https://github.com/extism/csharp-pdk/blob/master/samples/SamplePlugin/Functions.cs#L9

Currently you have to write the C glue code manually: https://github.com/extism/csharp-pdk/blob/master/samples/SamplePlugin/native.c#L11

[pavelsavara]

We also need the opposite: Exporting functions

That would be [UnmanagedCallersOnly] and I think both will need further discussion on design.
Note, I don't know how large portion of above would be in Net8.

Also there trouble is sharing memory between caller and called code. We will implement this assuming shared memory (with the host engine) and passing pointers.

And the "WASI component model" with isolated memory, lowering/lifting etc will need different attributes in the future future.

[MichaelPeter]

Can you help me understand how WASI helps in the 1st case over just running dotnet on the hardware today? I see the benefit for platform owners that want to run anything, but I'm having a hard time understanding how it helps developers? What does it mean to build and deploy a WASI service in this situation? Where are you deploying? What orchestrates your services? Without k8s what does networking?

These are very good questions and I see too: what benefit has WASI that I can not already do with Native Applications?

I see Wasmtime or different Wasm runners here as Platform that provides Networking, at least for now on a single maschine for Platform Owners. But here the WASI Commuity Group is not yet far enough with Networking and many other things...
Maybe there will be a more lightweight platform indipendent Kubernetes just for WASI Containers.

Alternativly frameworks like Aspire could abstract away the underlying Networking for WASI Runner-Platform and/or Kubernetes Platform.
But here again, I can do that already on windows/linux too.

Where do I deploy? Everywhere, where I can start a Wasi Runner (Windows Server, Developer/Sales Laptop,
Custom Hardware like Production Lines or devices which are not powerfull enough for a whole Kubernetes Clusters).

What are the Advantages for the Developer: For Testing he doesn't need a whole Kubernetes Cluster on his Developer PC, only a WASI runner.

But then still Who does Updating? there are WASI/WASM Container registries, but no Gitops Platforms yet like ArgoCD/Flux to automatically update...

But as you said these are just Ideas and no concrete use cases
I am quite unhappy with my answer too and see it is not yet well thought out yet.

[davidfowl]

I see Wasmtime or different Wasm runners here as Platform that provides Networking, at least for now on a single maschine for Platform Owners. But here the WASI Commuity Group is not yet far enough with Networking and many other things...

I meant for distributed systems, not networking APIs that WASI may describe.

Maybe there will be a more lightweight platform indipendent Kubernetes just for WASI Containers.

Sure but that has yet to manifest. I'm also not convinced it will be that different to Kubernetes at the core.

What are the Advantages for the Developer: For Testing he doesn't need a whole Kubernetes Cluster on his Developer PC, only a WASI runner.

You can run your apps today locally on your PC without Kubernetes. This isn't a feature unique to WASI.

I'm very supportive of the work to make .NET work with WASM on the server side, but the ecosystem barely exists so the benefits called out are hypothetical and in the early idea stage. There are a few platforms and tools that can run WASM binaries but from a .NET developer point of view, it seems like an implementation detail.

[SteveSandersonMS]

This is a great conversation and helps to flush out a lot of the ambiguity that surrounds WASI today. It's important to know that WASI (i.e., a combination of API interface definitions for things like HTTP requests, plus tooling like wasmtime.exe for executing wasm modules with support for those APIs) does not itself replace or even compete with Kubernetes as a multi-process/machine/container app orchestrator. WASI/wasmtime has no concept of deployments, scaling, service discovery, or pretty much anything except what native code could do if you deployed it to a super minimal OS like on an embedded device. It does have the benefits of hardware abstraction, better sandboxing, and faster startup compared with a traditional container.

Long term it's completely possible that K8s devs will commonly run WASI components in preference over traditional containers within their Kubernetes clusters. Or maybe that some WASI-first K8s alternative will emerge, though as @davidfowl says it would probably look the same as Kubernetes from the point of view of the person deploying and maintaining the cluster itself. However, neither of these things are definite, and the WASI ecosystem remains at an early stage.

[sec]

Having possibility to run ASP.NET WebApi project on system that don't have .net supported (ex. *BSD and/or exotic arch) would be +1 for me. It was possible using https://github.com/SteveSandersonMS/dotnet-wasi-sdk and implementing http host under wasmrunner to interop with .net or using the one with WASI tcp-level where available - is/will that be planned/supported in future?

[davidfowl]

It does have the benefits of hardware abstraction, better sandboxing, and faster startup compared with a traditional container.

Right! I was hoping somebody would have a scenario around that.

Having possibility to run ASP.NET WebApi project on system that don't have .net supported (ex. *BSD and/or exotic arch) would be +1 for me. It was possible using https://github.com/SteveSandersonMS/dotnet-wasi-sdk and implementing http host under wasmrunner to interop with .net or using the one with WASI tcp-level where available - is/will that be planned/supported in future?

Are you expecting a very small binary with a tiny performance hit? WASI is experimental and we don't be shipping anything non-experimental on top of it until it goes stable. Our path for WASM on the server should be based on the work we've been doing to make ASP.NET Core NativeAOT compatible (and this is a long journey 😄).

[RReverser]

Our path for WASM on the server should be based on the work we've been doing to make ASP.NET Core NativeAOT compatible (and this is a long journey 😄).

FWIW we're currently experimenting with Wasm support via NativeAOT-LLVM experiment (https://github.com/dotnet/runtimelab/tree/feature/NativeAOT-LLVM) and had a very good experience performance-wise. The only blockers are that it's experimental and that it currently builds only on Windows. Other than that, it's pretty competitive with Wasm compiled from Rust (except for binary size, but that's not very important to us anyway), especially compared to the Mono interpreted version.

Hoping that the cross-platform variant of NativeAOT will get to similar level feature- and performance-wise someday, or that NativeAOT-LLVM experiment will make it into mainstream.

That said, in our project we're not interested in WASI but in pure Wasm as we provide custom host functions. WASI target is just means to an end because in .NET there is currently no option for wasm32-unknown-unknown targets like there is in other compiles (C / C++ / Rust / Zig), so using WASI, shimming out WASI imports by linking with custom C file, and hooking up own imports / exports is the only path for now.

[sec]

Right, I was just hoping to use wasi-wasm with AspNetCore more easily or at least somehow-supported. The way you wrote, is what basically @SteveSandersonMS did in his repo - would be nice to have it under .net 8 (which I was thinking this issue is also about). more docs/examples for newbie on how to get into hacking this would be 🚀

@davidfowl As for performance and binary size - that's something I wouldn't care for at the start, as having possibility to run .net code on new platform/os without "native" runtime would be more important IMO (sure NativeAOT would be way better, but as you said, it's a journey :)

[davidfowl]

@sec Then the current support is likely fine for you without native aot 😄

[MichaelPeter]

Another usage scenario are server side plugins, @SteveSandersonMS showed it already in his demos, but wanted to mention it again.

On self hosted environments by customers, computation is not that expensive and our server side applications can load Plugin DLLs (from us or third party) and run them into the server process. There is always the risk of memory leaks, infite loops and reduced performance but it can be tolerated.

On Cloud environments this is not tolerable anymore, since one plugin DLL could bring down all customers, also there is the risk of data of other customers can be accessed. So third party Plugin Developers need to host REST/GRPC Services for their plugins which then need to be integrated. This is much more complex and much slower than a DLL. Or there need to be a whole infrastructure for hosting third party docker containers.

With WASI, we could still load the WASI-File-Plugins in Our Application, data of other customers could not be accessed (or at least an acceptable risk if no error on our side), we could limit the amount of CPU resources to disable slow plugins
and what would be importaint - if the used CPU time would be measurable - we could even charge third parties for the resources their plugins take, so they have a motivation to make them actually more efficent.
Not to mention the performance gain from WASI call vs REST call.

It also would be importaint that it can be configured that only certain Rest/Socket resources can be accessed, or for example only external and no Lan-Endpoints. (be it by IP-Ranges or other means)

[davidfowl]

With WASI, we could still load the WASI-File-Plugins in Our Application, data of other customers could not be accessed (or at least an acceptable risk if no error on our side), we could limit the amount of CPU resources to disable slow plugins
and what would be importaint - if the used CPU time would be measurable - we could even charge third parties for the resources their plugins take, so they have a motivation to make them actually more efficent.
Not to mention the performance gain from WASI call vs REST call.

AFAIK WASM runtimes (the ones I've seen) don't let you limit CPU usage of running code (you can limit the memory)

.NET process host -> Some WASM runtimes-> .NET code compiled to WASM running inside of those runtimes.

Of course, these systems are not "just secure" as you need to audit the host code and WASM runtime code to make sure bugs don't lead to leaking customer data across...

I think we will see plugins using WASM more and more so that's a reasonable scenario.

[mhmd-azeez]

AFAIK WASM runtimes (the ones I've seen) don't let you limit CPU usage of running code

Wasmtime has the concept of "fuel": https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.consume_fuel

But, it's different from docker's cpu limits, it's more about preventing infinite loops

[MichaelPeter]

Another point - is debuggability of production environments vs. chiseled-docker

In one project we switched to chinseled dotnet containers a few days ago and now we have the problem that debugging is much more limited of production environments since there is no shell.
Logging into the container and creating a memory dump? Not possible anymore without a shell,
Update a file? Also not possible.
Executing a curl/wget from within the container? Also not possible.

Now one could argue well then keep the shell installed for production, well then the container is bigger and its a potential security risk.
A debugging sidecar? Not within the container, except written in the same language.

Wasi would allow a "sidecar"-wasi written for example in rust for .NET, which could be included in the "wasi-container"
Memory dumps?, Viewing Thread Stacks? Sure. (https://docs.wasmtime.dev/examples-debugging-core-dumps.html)
Debugging within the Runtime? Also possible.

But yes, most of this tooling doesn't exist yet.
And you can with "drawbacks" also do that with docker.

[RReverser]

Is there any way to produce raw Wasm MVP files from .NET 9 after #104683 has landed?

We've been "piggy-backing" on .NET's Wasi target to produce Wasm files targeted for custom hosts, as, unlike C/C++/Rust/etc .NET doesn't have support for raw ("hostless") Wasm output and WASI is the closest target where we could simply stub out all the imports during compilation and rely on UnmanagedCallersOnly and similar attributes to add custom imports/exports instead.

This has been possible starting from the original @SteveSandersonMS' Wasi.Sdk and up until and including .NET 8.

I now wanted to try and test how hard it would be to migrate to .NET 9 preview as it has some exciting Wasm features - in particular, AOT and [WasmImportLinkage] - but it appears that .NET 9 did a hard switch to component-based output that is 1) tied a lot more tightly with the WASI imports, making them harder to stub out and 2) means that we can no longer target engines without Wasm components support, which is still the majority of non-WASI engines.

Which brings me to the crux of my question - is there any way path to opt-out from Wasm component output or, even better, an official example that shows how to produce a raw "hostless" Wasm in plain old MVP format, going to be provided in .NET 9 or does this mean we're stuck with .NET 8 with its slow interpreter mode for IL bytecode for the foreseeable future?

UPD: I should probably add that, by decomposing components into individual Wasm files using wasm-tools component unbundle, I can see that one of those files has basically the same shape as what we used to get before, but I wouldn't want to rely on essentially implementation details and extract it from the bundled output as part of the build process. Ideally, there would be an MSBuild option instead that I could use to request statically linked Wasm MVP output.

[pavelsavara]

@RReverser

We switched to WASI preview 2 and component model in Net9 Preview 7.
We don't plan to support preview 1 or WASIX.

We now depend on wasi:http component import directly.

We don't have dev bandwidth to support multiple build configurations, I'm sorry.
WASI support is still experimental and moving fast.

[RReverser]

I imagine that's going to break quite a few users in similar positions to us.

Out of curiosity, what was the driver behind that decision? Wasm components are still in rather raw stages, and the engine support is pretty poor compared to regular Wasm. While it's interesting to watch its development, it seems rather too early to switch to it as the primary output format for stable .NET version, cutting off majority of engines other than I guess Wasmtime.

Perhaps there is some wasm-ld have some flag to request Wasm MVP output, where those component imports would become plain C imports instead? As mentioned above, I can see that the main raw Wasm inside the component bundle looks exactly like what we'd need - here are its imports:

Import[32]:
 - func[0] sig=3 <__imported_wasi_snapshot_preview1_environ_get> <- wasi_snapshot_preview1.environ_get
 - func[1] sig=3 <__imported_wasi_snapshot_preview1_environ_sizes_get> <- wasi_snapshot_preview1.environ_sizes_get
 - func[2] sig=40 <__imported_wasi_snapshot_preview1_clock_time_get> <- wasi_snapshot_preview1.clock_time_get
 - func[3] sig=22 <__imported_wasi_snapshot_preview1_fd_advise> <- wasi_snapshot_preview1.fd_advise
 - func[4] sig=1 <__imported_wasi_snapshot_preview1_fd_close> <- wasi_snapshot_preview1.fd_close
 - func[5] sig=3 <__imported_wasi_snapshot_preview1_fd_fdstat_get> <- wasi_snapshot_preview1.fd_fdstat_get
 - func[6] sig=3 <__imported_wasi_snapshot_preview1_fd_fdstat_set_flags> <- wasi_snapshot_preview1.fd_fdstat_set_flags
 - func[7] sig=3 <__imported_wasi_snapshot_preview1_fd_filestat_get> <- wasi_snapshot_preview1.fd_filestat_get
 - func[8] sig=24 <__imported_wasi_snapshot_preview1_fd_filestat_set_size> <- wasi_snapshot_preview1.fd_filestat_set_size
 - func[9] sig=41 <__imported_wasi_snapshot_preview1_fd_pread> <- wasi_snapshot_preview1.fd_pread
 - func[10] sig=3 <__imported_wasi_snapshot_preview1_fd_prestat_get> <- wasi_snapshot_preview1.fd_prestat_get
 - func[11] sig=2 <__imported_wasi_snapshot_preview1_fd_prestat_dir_name> <- wasi_snapshot_preview1.fd_prestat_dir_name
 - func[12] sig=6 <__imported_wasi_snapshot_preview1_fd_read> <- wasi_snapshot_preview1.fd_read
 - func[13] sig=41 <__imported_wasi_snapshot_preview1_fd_readdir> <- wasi_snapshot_preview1.fd_readdir
 - func[14] sig=42 <__imported_wasi_snapshot_preview1_fd_seek> <- wasi_snapshot_preview1.fd_seek
 - func[15] sig=6 <__imported_wasi_snapshot_preview1_fd_write> <- wasi_snapshot_preview1.fd_write
 - func[16] sig=16 <__imported_wasi_snapshot_preview1_path_filestat_get> <- wasi_snapshot_preview1.path_filestat_get
 - func[17] sig=43 <__imported_wasi_snapshot_preview1_path_open> <- wasi_snapshot_preview1.path_open
 - func[18] sig=17 <__imported_wasi_snapshot_preview1_path_readlink> <- wasi_snapshot_preview1.path_readlink
 - func[19] sig=2 <__imported_wasi_snapshot_preview1_path_unlink_file> <- wasi_snapshot_preview1.path_unlink_file
 - func[20] sig=6 <__imported_wasi_snapshot_preview1_poll_oneoff> <- wasi_snapshot_preview1.poll_oneoff
 - func[21] sig=0 <__imported_wasi_snapshot_preview1_proc_exit> <- wasi_snapshot_preview1.proc_exit
 - func[22] sig=10 <__imported_wasi_snapshot_preview1_sched_yield> <- wasi_snapshot_preview1.sched_yield
 - func[23] sig=3 <__imported_wasi_snapshot_preview1_random_get> <- wasi_snapshot_preview1.random_get
 - func[24] sig=1 <__wasi_preview1_adapter_close_badfd> <- wasi_snapshot_preview1.adapter_close_badfd
 - func[25] sig=0 <__wasm_import_poll_pollable_drop> <- wasi:io/poll@0.2.0.[resource-drop]pollable
 - func[26] sig=0 <__wasm_import_streams_input_stream_drop> <- wasi:io/streams@0.2.0.[resource-drop]input-stream
 - func[27] sig=0 <__wasm_import_streams_output_stream_drop> <- wasi:io/streams@0.2.0.[resource-drop]output-stream
 - func[28] sig=0 <__wasm_import_udp_udp_socket_drop> <- wasi:sockets/udp@0.2.0.[resource-drop]udp-socket
 - func[29] sig=0 <__wasm_import_udp_incoming_datagram_stream_drop> <- wasi:sockets/udp@0.2.0.[resource-drop]incoming-datagram-stream
 - func[30] sig=0 <__wasm_import_udp_outgoing_datagram_stream_drop> <- wasi:sockets/udp@0.2.0.[resource-drop]outgoing-datagram-stream
 - func[31] sig=0 <__wasm_import_tcp_tcp_socket_drop> <- wasi:sockets/tcp@0.2.0.[resource-drop]tcp-socket

So, while I totally understand lack of bandwidth for actual development & support, perhaps there is a way to just provide a different link-stage flag so that .NET would produce just this one single file, which already has the required shape? We can do the rest of the stubbing ourselves.

[pavelsavara]

@RReverser

You could try disable wasm-component-ld and return back to wasm-ld.
Possibly passing -fuse-ld=lld could do the trick for you.
See relevant LLVM change of the default linker.

We are also passing .wit files to the linker, which wasm-ld would not understand. You may need to hack around that.
We can't support targeting wasip1 libc, that would be too much of conditional compilation (and mental overhead).

Here is WASM & WASI ABI, I'm not sure which of them would apply.

Out of curiosity, what was the driver behind that decision?

"Skate to where the puck is going, not where it has been."

[RReverser]

Possibly passing -fuse-ld=lld could do the trick for you.
See relevant LLVM change of the default linker.

Thanks, this is helpful, going to take a look.

We are also passing .wit files to the linker, which wasm-ld would not understand. You may need to hack around that.

Yeah I suspect this is going to be a problem, too. I looked at it briefly before, and I think I could hack around it with MSBuild's Remove=... as those WIT linker args are passed as separate ItemGroup items, but that's going to be very fragile as it would need to match a linker arg by wildcard pattern... Would you be open to accepting a PR that adds an unofficial conditional MSBuild flag instead that skips the WIT files when set?

We can't support targeting wasip1 libc, that would be too much of conditional compilation (and mental overhead).

That is fine, since we are going to stub them out anyway, it doesn't matter which version is used.

On the C ABI side it still behaves like a regular C import, after all, so declaring stubs isn't very different from the original preview. It's really just the components + WIT that cause issues, which is why I'm hopeful that what we want is achievable with purely a link-time change.

"Skate to where the puck is going, not where it has been."

Heh, I agree with the sentiment, just saying it feels... risky / early for a switch, given the very limited native engine support. I liked WASI p1 for its simplicity and compatibility with any regular Wasm, and was one of probably dozens of people who made their own in-browser implementations at the time because it was just a matter of loading same Wasm file but with custom imports. Oh well, either way that's beside the point for this particular usecase.

[pavelsavara]

Would you be open to accepting a PR that adds an unofficial conditional MSBuild flag instead that skips the WIT files when set?

For Net10 possibly yes. But I'm afraid we will break it again ... let's give it a try.

[enghch]

@RReverser Did you ever get this workaround working? I'm in the same boat where I'm trying to code to an existing host that only supports modules, not components. .NET 9 preview 6 was working for me, but for some reason I couldn't get it to include native assets.

[nilslice]

This definitely seems like a misstep. There is practically no use of WASI Preview 2[0] in the ecosystem, and very few runtime maintainers are interested in supporting this moving target. WASI Preview 1 is still in significant demand, and it would be a shame to have to drop .NET support in our projects because of this decision.

"Skate to where the puck is going, not where it has been"

The puck definitely does not seem to be moving in the direction you're alluding to with this change. Based on the component model implementation across the runtime landscape, this severley limits the utility of .NET in the Wasm ecosystem. If that is the intention of the team here, then I suppose you are making the right call.

[0]: from https://crates.io/crates/wasi

Note the actual downloads are WASI Preview 1, with barely any activity for the Preview 2 versions.

[kg]

My personal position as one of the original creators of WebAssembly is that "skating towards where the puck is going" has always been necessary to deliver a good developer experience, and it will continue to be necessary. It's not always possible to predict where the puck is going to end up, but following the standards process is decent way to go about it.

very few runtime maintainers are interested in supporting this moving target ...
Note the actual downloads are WASI Preview 1, with barely any activity for the Preview 2 versions.

By the same logic used here to argue for staying on p1 forever (look at this linear scale graph showing usage of a widely deployed piece of technology vs an emerging technology), it would i.e. be appropriate to only support a single dominant web browser and ignore every other browser, based on current usage statistics. At one point, the proven technology was asm.js - widely supported and widely used - while the emerging technology was WASM. In the same way, one could argue that WASI itself shouldn't be supported, since WASI usage is tiny in comparison to usage of client web browsers. Surely that's not the goal?

Given the amount of time it takes for core runtime changes to percolate through the ecosystem into developers' hands, and then the time it takes for developers to adopt a new core runtime version and deploy it in their applications, it's not sufficient to ask "what does WASM look like today? what does WASI look like today?" because by the time your answer(s) end up on an end user's computer or on a server in the cloud, years have passed. It's not sufficient to just say "this is the wrong answer right now" and use that to close off any forward-looking development.

Some key questions are:

• What do end users want?
• What will end users' devices look like by the time this software ships?
• What changes need to be made in order to deliver what end users want on the devices and runtimes they'll have by the time this software ships?

Just off the top of my head, I don't see a good solution for HTTP in WASI p1, so I feel those three questions are illuminating in this context.

My personal advice in this context would be to consider stating what the user needs are and how those needs are best served by staying still instead of moving forward, or alternately, suggest which direction the forward movement should be aimed in and how that will serve users.

[yoshuawuyts]

@nilslice Hi there, Rust Project member here. I'd be careful not to read too much into the download data of one specific Rust package. The WASI 0.1 (nee wasm32-wasi) target has been a tier 2 stable target ¹ for five years. The WASI 0.2 target has been on tier 2 for negative three weeks: it is going to be released next month as part of Rust 1.82 (October 17th, 2024).

This is relevant because in order for crates to support both WASI 0.1 and also introduce support for WASI 0.2, a compiler target cfg is required. This allows crate authors to conditionally compile for different targets, and looks something like this:

#[cfg(all(target_os = "wasi", target_env = "p1"))]
mod wasip1 { /* WASI 0.1 items go here */ }

#[cfg(all(target_os = "wasi", target_env = "p2"))]
mod wasip2 { /* WASI 0.2 items go here */ }

In order for crates to test whether they work on CI they require a working WASI 0.2 toolchain, which in turn requires having a prebuilt compiler toolchain available. While it was technically possible to build your own WASI 0.2 toolchain for Rust before Rust 1.82, we've recommended against people doing that. That has meant that targeting WASI 0.2 from existing libraries essentially hasn't been possible. This will change with the upcoming Rust 1.82 release, at which point we will likely see a gradual roll-out of support for WASI 0.2 throughout the ecosystem.

I hope that provides some insight into the evolution of Rust's WASI targets. If you'd like to read more, please see the post: Changes to Rust's WASI targets, as well as the draft for the upcoming release: The wasm32-wasip2 Target has Reached Tier 2 Support.

Footnotes

1. A target in Rust being "tier 2" means it is guaranteed to build and pre-built compiler toolchains are available to be installed via the rustup tool. This is the support tier required to practically support running a toolchain in CI. ↩

[mattjohnsonpint]

We use Wazero as our WASM host runtime. I was planning to offer C# as a target guest language, but I guess since Wazero has voted no to WASI-p2 and .NET has voted no to WASI-p1, that sadly we'll just have to tell our customers to pick a different language.

See

• Plans to support component model? tetratelabs/wazero#2200
• WASI Preview 2 support tetratelabs/wazero#2289

[nilslice]

@yoshuawuyts, hi - I don't think the point you're making really lands here or is related to the .NET support concern, but thanks!

I'd be careful not to read too much into the download data of one specific Rust package.

I have been reading and following these closely for a few years, it's always a good proxy to measure interest. Considering it's my job to know what users want from Wasm, I read a lot of crates.io and other package manager data.

The WASI 0.2 target has been on tier 2 for negative three weeks: it is going to be released next month as part of Rust 1.82 (October 17th, 2024).

Wasip2 launched in January of this year (WebAssembly/WASI#577), so I'd put the starting line for adoption metrics there. It's had nearly zero uptick, except from a few insiders within the Bytecode Alliance. This is despite countless strong pushes, conferences, and other evangelism. It's just not sticking.

I deeply care about WebAssembly, and have its best interest in mind, and I do not see the ecosystem having voted with their usage of Wasip2. Now, maybe if it really is that the Rust target alone is the winning solution, then that will change. But it still does NOT address anything to do with this thread, which is squarely about .NET tooling compiling to core standard Wasm Modules vs. non-standard unadopted Wasm components.

This is where the problem lays, and I worry will further fragment the ecosystem and at the same time strip .NET languages from their utility to Wasm projects.

If you'd like to read more, please see the post: Changes to Rust's WASI targets, as well as the draft for the upcoming release: The wasm32-wasip2 Target has Reached Tier 2 Support.

I have read this, and saw the problematic release and reversal of this announcement. It's not the most reassuring state of things to now think about depending on this target in any way.

[yoshuawuyts]

@yoshuawuyts, hi - I don't think the point you're making really lands here or is related to the .NET support concern, but thanks!

@nilslice ? - I was directly responding to your comment in #65895 (comment), where you claim that the downloads of a single Rust ecosystem crate are indicative of broader WASI 0.2 ecosystem adoption. You use that to further the argument that the dotnet maintainers should shy away from supporting WASI 0.2. I didn't make the connection between Rust and dotnet, you did.

Posting just the screenshot on its own can be misleading as it omits context. If you're going to discuss download counts, it seems relevant to explain that library authors can't practically add a dep on wasi@0.13 until Rust 1.82 which won't be released for another three weeks. Whereas the older version of the library has been around for five years. It should be obvious that download counts will be skewed and are not indicative of any broader trends or interests.