intent to discontinue about wasm HOT 7 OPEN

We're quite aligned on the importance of interop, and you might have noticed our recent efforts on things https://dart.dev/guides/libraries/c-interop, like https://dart.dev/guides/libraries/java-interop and https://dart.dev/guides/libraries/objective-c-interop.

However, there is only so much we can cover, so we're trying to focus on things that are at the lowest level of abstraction and thus have to be in the SDK itself. Something like the present package is at least technically setup to be at a higher level of abstraction, and we're hoping that the wider community might take it on.

from wasm.

Hi

I have been working on a package that provides similar functionalities, perhaps if anyone is interested they could try it out. It uses the wasmtime runtime and the wasmi interpreter. I just published it yesterday https://github.com/juancastillo0/wasm_run. If anyone would like use it or share some feedback that would be great!

It can compile and execute wasm using wasmtime and, for platforms that do not support it (iOS), wasm_run will use the wasmi interpreter. The primary reason to implement a different package from package:wasm was to support all platforms. It also supports the web using the browser's runtime and package:wasm_interop. WASI is supported in all platforms (including web with an in-memory file system). It uses flutter_rust_bridge to generate the native bindings and we also provide package:wasm_run_flutter that fetches the right binaries for each platform.

There is also a work-in-progress package:wasm_wit_component to generate Wasm Interface Types (WIT) bindings for Dart, which significantly improve the interop story. An example is the wit parser and generator itself that is implemented in Rust and compiled to a wasm module that follows a WIT package definition. package:wasm_run, with the bindings generated from the WIT file, executes the wasm module in the dart run wasm_wit_component:generate CLI to generate the Dart code from wit files.

Thanks for all your work!

from wasm.

Thank you for the heads-up.

@devoncarew I think that this package should not be archived because many challenges that this package has to overcome don't seem to have a good solution yet and are actively being worked on by others (e.g. #116 by the WIT efforts, #127 by e.g. wasmtime). I believe there are still too many open questions over which neither the Dart teams nor the Dart ecosystem has any control over and I think it would be best to just wait and see how the WASM ecosystem continues to evolve first.

There seems to be a lot of momentum behind WASM as a technology and (everybody seems to be on the WASM-train). I think that archiving this package would send a pretty negative signal to everybody. I personally wouldn't mind if this package goes into hibernation for another year.

from wasm.

WASM is like the "grand unified interface" of interoperability within the software development community

Yeah, I completely agree here. Wasm can help solve the many-to-many problem for algorithms; if you can consume wasm in your language or runtime, you can take advantage of all the best of breed algorithm implementations authored in other languages (for compression, image codecs, crypto, I18N, ...).

from wasm.

cc @modulovalue

from wasm.

These are the main challenges I see that need to be overcome:

• It's hard to ship packages with native code in the Dart ecosystem. We wrap the Wasmer runtime, which is a Rust library, so that makes it pretty inconvenient to use this package at the moment. I also never got the Wasmer build working for iOS. We're working on solving this problem independently of this package, through the native assets CLI. Once that lands, it will be much easier to use this package (no more manually running the build script). This should also solve the iOS build issues.
• As you mentioned, there's no JIT on iOS. One solution to this is to use Wasmer's AOT mode. An older version of this package supported that, but I removed it because it didn't work quite as I expected and needed a redesign (Wasmer's AOT compiled wasm modules are not cross platform, so we'd need to figure out cross compilation to target iOS etc, and now we're back to shipping binaries per platform 😕). Alternatively an interpreted runtime could be used (Wasmer probably has a mode for that).
• For generating bindings, that should probably be a distinct package (like how dart:ffi has package:ffigen).

I don't really see how keeping this package alive helps resolve these issues. I can see clear solutions to each of these that are either already possible, or actively being worked on. I don't see anything else in this package that requires input from the Dart team specifically. So, there's no reason this package can't be forked and maintained by the community.

It makes more sense for the Dart team to focus our efforts on the things that require changes at the VM level, or are otherwise foundational, like the native assets CLI I mentioned, or my current async callbacks project. These are changes that will improve interop with all languages, not just wasm.

Although we're deprecating this package, we're definitely not ignoring wasm. Quite the opposite. Compiling Dart/Flutter to wasm is actively being worked on, and was demoed at IO.

@modulovalue I encourage you to fork this package, make all those API changes you were trying to land in this package, then publish it yourself (under a different name, to avoid confusion).

from wasm.

I think there are no fundamental disagreements here, it's just that there is a difference in opinion about what to focus on.

It seems to me that a big reason why dart is not being adopted more is its lack of well-tested and proven-in-production packages. C, Python, JS/TS, Java/Kotlin all have huge ecosystems that are orders of magnitude bigger than the Dart ecosystem.

WASM is like the "grand unified interface" of interoperability within the software development community and essentially everybody is on board. I think that the Dart ecosystem could immensely benefit from being able to execute WASM as this could help it close this ecosystem gap.

Of course, I can't force anyone to do anything. I just hope that this opinion has been considered. cc @kevmoo @mit-mit

I encourage you to fork this package

I will most likely have to do that. Unfortunately, I don't have the resources to develop and support a general purpose solution for the whole community that supports all platforms.

from wasm.