WASI 0.2.0 and Why It Matters • Hacker News Board

Re: WASI 0.2.0 and Why It Matters

#21

Post by callahad » Fri, Jan 26, 2024, 4:29 PM UTC

PedroBatista wrote: post #6

About Wasm and WASI, I'll try ( and probably fail ) to escape the HN stereotype so please forgive me. I've been more of less following this for a decade ( since asm.js ), I still fail to see a practical use for this. And I mean a generalized use in real products and systems that stand the test of being an actual economically viable product, not cool demos which running Doom is probably the best one from a technical p…

You almost certainly use WebAssembly today in widely deployed / commercial products without realizing it.

Figma, Microsoft Flight Simulator, Disney+, Amazon Prime Video, Photoshop for Web, 1Password, and uBlock Origin all implement significant portions of their applications as WebAssembly modules.

Many of those examples are building their Wasm modules from Rust codebases.

From what I can see, Rust and Wasm have undeniably crossed the chasm into pragmatic, mainstream applications. The serverside Wasm ecosystem is still nascent, but that's what initiatives like WASI and the Component Model are designed to address. Yesterday's vote to launch WASI Preview 2 is a huge step towards building a stable, interoperable foundation for WebAssembly outside of web runtimes.

Re: WASI 0.2.0 and Why It Matters

#22

Post by pjmlp » Fri, Jan 26, 2024, 4:31 PM UTC

Capricorn2481 wrote: post #12

pjmlp wrote: post #7

WASI aka redoing CLR Common Language Specification. https://en.wikipedia.org/wiki/Common_Language_Infrastructure https://ecma-international.org/publications-and-standards/st... > This Standard defines the Common Language Infrastructure (CLI) in which applications written in multiple high-level languages can be executed in different system environments without the need to rewrite those applications to take into consid…

I've seen you comment this on a lot WASM posts (often as a criticism) so I have to ask, as someone who doesn't have knowledge of either, what is bad about this? Even if Web Assembly only has a subset of what CLR offers, isn't it a good thing a standard has been created that people are actually able to implement? If Microsoft was not aligned with developers in the early 2000's, that failure is on them.

Presenting as if it was the first done anyone has done any of this, UNCOL was the first time such ideas came to be, in 1958.

Plenty of historical attempts to dive into, since 1958.

Now we have startups redoing Java and .NET application servers, with Kubernetes, WebAssembly, WASI, and YAML spaghetti, because that is so much better.

Edge devices running bytecode? That is so last century.

Re: WASI 0.2.0 and Why It Matters

#23

Post by flohofwoe » Fri, Jan 26, 2024, 4:31 PM UTC

PedroBatista wrote: post #13

make3 wrote: post #11

Earlier quoted context omitted.

We've seen a lot of ppl write electron apps because they're portable. I see this as electron/jvm for code that already exists in non vm languages, so that in theory you don't need to do nearly as much rewriting, or any at all. that's pretty cool.

Yes, that's the idea. In theory.. :)

I recently made a command line assembler tool written in C in the early 90's run in a VSCode extension via WASI just by compiling with the WASI SDK, IMHO that's pretty cool:

https://floooh.github.io/2023/12/31/vscode-wasm-wasi.html

(same with my home computer emulators, but those were written right from the start with the web as "just another platform" in mind: https://floooh.github.io/tiny8bit/)

Re: WASI 0.2.0 and Why It Matters

#24

Post by pjmlp » Fri, Jan 26, 2024, 4:31 PM UTC

stetrain wrote: post #19

pjmlp wrote: post #7

WASI aka redoing CLR Common Language Specification. https://en.wikipedia.org/wiki/Common_Language_Infrastructure https://ecma-international.org/publications-and-standards/st... > This Standard defines the Common Language Infrastructure (CLI) in which applications written in multiple high-level languages can be executed in different system environments without the need to rewrite those applications to take into consid…

The tech world is full of standards that didn't catch on universally for one reason or another. If a new attempt can try the same idea, learn some lessons, and get more traction then I think that's a good thing.

As long as one acknowledges the trailed path I guess.

Re: WASI 0.2.0 and Why It Matters

#25

Post by pjmlp » Fri, Jan 26, 2024, 4:32 PM UTC

kcolford wrote: post #15

pjmlp wrote: post #7

WASI aka redoing CLR Common Language Specification. https://en.wikipedia.org/wiki/Common_Language_Infrastructure https://ecma-international.org/publications-and-standards/st... > This Standard defines the Common Language Infrastructure (CLI) in which applications written in multiple high-level languages can be executed in different system environments without the need to rewrite those applications to take into consid…

That’s only used for .NET and other ms technologies. There is a totally different ecosystem surrounding WebAssembly.

Yeah, that isn't as fashionable and with startup opportunities.

Re: WASI 0.2.0 and Why It Matters

#26

Post by pjmlp » Fri, Jan 26, 2024, 4:33 PM UTC

stanac wrote: post #17

pjmlp wrote: post #7

WASI aka redoing CLR Common Language Specification. https://en.wikipedia.org/wiki/Common_Language_Infrastructure https://ecma-international.org/publications-and-standards/st... > This Standard defines the Common Language Infrastructure (CLI) in which applications written in multiple high-level languages can be executed in different system environments without the need to rewrite those applications to take into consid…

Are you saying that they are just copying MS or MS is controlling the standard, or that we don't need the standard because we have CLR? Regardless I think WASM and WASI are huge step in right direction since most if not all relevant languages are going to support it.

Not only MS, plenty of past attempts since UNCOL in 1958.

Re: WASI 0.2.0 and Why It Matters

#27

Post by mc_woods » Fri, Jan 26, 2024, 4:33 PM UTC

PedroBatista wrote: post #6

About Wasm and WASI, I'll try ( and probably fail ) to escape the HN stereotype so please forgive me. I've been more of less following this for a decade ( since asm.js ), I still fail to see a practical use for this. And I mean a generalized use in real products and systems that stand the test of being an actual economically viable product, not cool demos which running Doom is probably the best one from a technical p…

There are compelling applications for WASM in the embedded space, here we run C / C++ applications and WASM supports this well. We can also run other languages compiled to WASM too.

On the server side this is less clear. Typically we don't write system level languages server side - we use other languages, like Ruby, Python, JavaScipt etc. These interpreted languages can run in WASM, but only as language interpreter inside the WASM interpreter - so they work, but they are not efficient. The benefit to the cloud / infrastructure provider is often not-clear, not when it's possible to run these very same applications in existing infrastructure. On the server side the benefit to the application developer is also not clear. There are few providers who have infrastructure to support WASM applications directly. You'd really need to see the big 3 cloud providers look at supporting WASM directly, without hypervisors / vm / container technology under it, to realize any performance improvements and hence pass on some cost benefit to the developer ecosystem.

"running stuff in the browser"; isn't old news. There are a growing number of applications that are migrating toward web-based UI and for these WASM is really useful. WASI-Preview2's benefits are not going to be realized in a browser, it's more for the non-web world....

Rust-Focus; yes, you are correct the existing technology, with the exception of perhaps WAMR and CloudEdge runtimes are rust based. As WasmTime is the only standalone technology which currently supports preview2, and it's written in rust, then the associated examples and tooling are naturally rust focused.

Re: WASI 0.2.0 and Why It Matters

#28

Post by jraph » Fri, Jan 26, 2024, 4:33 PM UTC

pjmlp wrote: post #7

WASI aka redoing CLR Common Language Specification. https://en.wikipedia.org/wiki/Common_Language_Infrastructure https://ecma-international.org/publications-and-standards/st... > This Standard defines the Common Language Infrastructure (CLI) in which applications written in multiple high-level languages can be executed in different system environments without the need to rewrite those applications to take into consid…

From your first link:

> Microsoft and its partners hold patents for CLI. Ecma and ISO/IEC require that all patents essential to implementation be made available under "reasonable and non-discriminatory (RAND) terms." It is common for RAND licensing to require some royalty payment, which could be a cause for concern with Mono. As of January 2013, neither Microsoft nor its partners have identified any patents essential to CLI implementations subject to RAND terms.

With such FUD, I guess no wonder CLI didn't have wider adoption.

The open source implementation of CLI was also left to the community, the main one being proprietary. If Microsoft & co wanted an actual usable standard, they could have done a better job.

Re: WASI 0.2.0 and Why It Matters

#29

Post by dartos » Fri, Jan 26, 2024, 4:34 PM UTC

pjmlp wrote: post #22

Capricorn2481 wrote: post #12

Earlier quoted context omitted.

I've seen you comment this on a lot WASM posts (often as a criticism) so I have to ask, as someone who doesn't have knowledge of either, what is bad about this? Even if Web Assembly only has a subset of what CLR offers, isn't it a good thing a standard has been created that people are actually able to implement? If Microsoft was not aligned with developers in the early 2000's, that failure is on them.

Presenting as if it was the first done anyone has done any of this, UNCOL was the first time such ideas came to be, in 1958. Plenty of historical attempts to dive into, since 1958. Now we have startups redoing Java and .NET application servers, with Kubernetes, WebAssembly, WASI, and YAML spaghetti, because that is so much better. Edge devices running bytecode? That is so last century.

What’s old is new again.

Edge devices running bytecode has its uses. Being an old idea doesn’t discredit it (neural networks were first described in the 70s)

At least WASI is a standard unlike flash or Java applets.

Re: WASI 0.2.0 and Why It Matters

#30

Post by flohofwoe » Fri, Jan 26, 2024, 4:35 PM UTC

mc_woods wrote: post #16

ilaksh wrote: post #3

That's amazing to see those things in WASI finally. But they also mention components. Does that mean components are part of the web assembly standard now? And am I correct in assuming that components are an option for projects where the functionality of WASI still isn't adequate?

The WebAssembly standard breaks into two parts, "core WASM" which is the spec the browsers use and everyone else. Then in the non-browser space there is WASI (system interface specification). The WASI-Preview 2 standard uses component model as the underlying mechanism for implementing the APIs it supports. It is not compatible with existing WASI functions... you need to change your binary with an adapter to get exist…

Ooof, that sounds like a mess tbh (traditionally, WASI could be described as "POSIX for WASM", and IMHO this sort of focus was just right, easy to communicate, easy to use).

When reading through all the things going into WASI Preview 2 (basically "everything and the kitchen sink", except for async/await(!) which goes into Preview 3) my first thought was: ok, this is what the second-system-effect looks like in practice.