[MuffinFlavored]

> Write a library in Rust and compile it to WASM

this misses the fact that (unless I'm wrong), WASM by itself can't really do anything like file system/network operations

I know that's not the main usecase of where to put WASM logic that needs to be performant (it's the opposite really)

I just think it's worth calling out that a WASM library really can't do much from what I understand. Like... basic math? You have to supply it (through a WASM runtime) interop to other functions it can call... I think?

Would love to be taught/proven wrong.

[nateabele]

This is where WASI (WebAssembly System Interface) comes in.

[TobyTheDog123]

But isn't WASI considered harmful?

I absolutely disagree with ASC's stance on this, but it seems that the AssemblyScript project at least wants nothing to do with that kind of thing:

[1] https://devclass.com/2022/09/08/assemblyscript-project-wasi-...

[2] https://www.assemblyscript.org/standards-objections.html

[3] https://github.com/WebAssembly/WASI/issues/401

[initplus]

I have a hard time taking this seriously, it's the objections of one individual who seems to be seeing ulterior motives behind WASI... I don't think their objections are really as strong as they make out. Big red "In violation" labels are a bit much.

WASI is trying to be a cross language API for use by multiple languages that target WASM. But the author wants this API to more closely follow existing JS conventions? Sure that's useful to JS/Web, but it's not useful for anyone else trying to target WASM with a language that's not JS. And if you want to target Web API's with JS, can't you already just write native JS?

Bikeshedding over string encoding for example and objecting to WASI's promotion of UTF-8 because it doesn't match the encoding used by JS.

[MuffinFlavored]

Let me ask you this. All nonsense aside about like... standard discussion and what not.

Say I write a Rust program to use `reqwest` to make a HTTP request to some API that is going to return me JSON.

I can compile it to... ELF with Rust I guess on Linux, or I can use Rust to compile it to:

> wasm32-wasi - when using wasmtime this is likely what you'll be using. The WASI target is integrated into the standard library and is intended on producing standalone binaries.

> wasm32-unknown-unknown - this target, like the WASI one, is focused on producing single .wasm binaries. The standard library, however, is largely stubbed out since the "unknown" part of the target means libstd can't assume anything. This means that while binaries will likely work in wasmtime, common conveniences like println! or panic! won't work.

> wasm32-unknown-emscripten - this target is intended to work in a web browser and produces a .wasm file coupled with a *.js file, and it is not compatible with wasmtime.

Say the Tokio async runtime works for wasm32-wasi (I don't think it does currently, I could be wrong) and reqwest + all of its network dependencies compile to wasm32-wasi (not sure if they do, I think there is progress) and say lite-json or some kind of JSON de-serizaliation works

Why would I compile + run as wasm32-wasi instead of stable-x86_64-unknown-linux-gnu?

Interesting links:

https://github.com/tokio-rs/tokio/issues/4827 - tokio support

https://github.com/async-rs/async-std/issues/505 - async-std support

https://www.reddit.com/r/rust/comments/h9bakg/could_not_find... - > There's no blocking implementation available for WASM. The WASM backend uses HTML APIs (fetch) and is supposed to run in a browser, where you can't block the event loop

[codeflo]

It's my understanding that WASI is using Unix-like abstractions, because they also target native execution, while the AssemblyScript would prefer web-like abstractions, because they exclusively target the browser. From your second link at least, this seems like the main technical complaint:

> Languages that would naturally fit the Web platform not only are overlooked, but WASI's self-imposed abstinence of Web concepts undermines other languages' interoperability potential with JS and the Web platform specifically.

The problem is that objectively, the web platform is garbage. Half-baked, weirdly incomplete abstractions, most of can only be rationally explained as either historical accidents or the aftermath of political fights on standards committees. Why would anyone base a new abstraction around those if they don't strictly have to?

[int_19h]

Considered harmful by whom?

After looking at the objections from these guys, they seem to boil down to, "but it makes non-web development more viable again, and that's bad for the web". The first part is true. The second part is arguable, but IMO if it is true, then balance needs to be restored.

[nullifidian]

More like dcodeIO and his AssemblyScript ambitions are considered harmful to us not having to live with the legacy hacks. The sad part is that it seems they have won, and the standard will be uglified on the fundamental level: https://github.com/WebAssembly/stringref/blob/main/proposals... Now the time came for WASI to submit, hence the "fatwa".

[TUSF]

> But isn't WASI considered harmful?

Lmao. The guy is just mad that WASI uses utf-8, as opposed to utf-16 (which is what Javascript uses)

[MuffinFlavored]

https://www.npmjs.com/package/as-fetch

this has 7 weekly downloads... I would expect more?

[styfle]

The as-fetch readme says undici is faster (which is the implementation of fetch that shipped in Node.js 18).

So 7 weekly downloads sounds about right for an unknown package that is slower.