Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WASI 0.2.0 and Why It Matters

wasmcloud.com

Post reply on HN
Print view View original

31–40 of 110 posts

Re: WASI 0.2.0 and Why It Matters

#31

Post by meheleventyone »

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…

For WASM in the browser I'd gesture at Figma for a economically viable product.

From my own perspective, which is browser based games, WASM opens up a lot of options. From using battle tested physics engines that are written in systems languages to the ability to access SIMD primitives. One of the underrated capabilities from that perspective to me is that floating point math is deterministic across browsers and platforms which is a bit of a holy grail for multiplayer games programming. Beyond that it promises to get faster and more efficient over time which is a good thing for performance heavy web apps.

Outside the browser MS Flight Sim uses WASM for the UI in part. WASI I know less about but doesn't seem totally crazy and in comparison to things like the JVM has a broader set of languages that can use it.

Re: WASI 0.2.0 and Why It Matters

#32

Post by flohofwoe »

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…

If the CLR wouldn't have focused on managed languages like C# but instead would have allowed to run C and C++ (unmodified, not the Franken-C++ Microsoft came up with multiple times which required substantial code modifications) more people would have taken it serious. Same with the JVM+Java+Oracle combo.

But then Emscripten came along and showed how it's done properly, and everything derived from that (asm.js, WASM, WASI) was just evolution at work.

Re: WASI 0.2.0 and Why It Matters

#34

Post by ryukafalz »

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.

You're right that the fundamental ideas behind WebAssembly and WASI are not particularly new.

The most exciting part about WASI for me, though, is that it's sticking to a capability-based interface and it's actually gaining a lot of traction. There are few examples of capability systems getting as much attention as this.

Re: WASI 0.2.0 and Why It Matters

#35

Post by Capricorn2481 »

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.

This just seems like an odd way to put people down, though. Some of us are not going to know the origin of most things that we use, but the reason for that is because those things weren't successful and web assembly is (relatively).

Re: WASI 0.2.0 and Why It Matters

#36

Post by spankalee »

pjmlp wrote: post #24
stetrain wrote: post #19

Earlier quoted context omitted.

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.

Who cares that much? Should WASI have an entire history of cross-platform computing in its spec?

Re: WASI 0.2.0 and Why It Matters

#37

Post by galangalalgol »

callahad wrote: post #21
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 unden…

Ruffle is a good example too. It brought most of the old flash content back to the web in a safe sandboxed way. To the point I could see people using the old adobe tools to make new content, if they haven't already.

Re: WASI 0.2.0 and Why It Matters

#38

Post by callahad »

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…

For folks looking to learn more, the Component Model documentation is pretty good! I like this excerpt for explaining the core vs component split:

> components interact only through the Canonical ABI. Specifically, unlike core modules, components may not export Wasm memory. This not only reinforces sandboxing, but enables interoperation between languages that make different assumptions about memory - for example, allowing a component that relies on Wasm GC (garbage collected) memory to collaborate with one that uses conventional linear memory.

Link: https://component-model.bytecodealliance.org/design/why-comp...

Re: WASI 0.2.0 and Why It Matters

#39

Post by baq »

ilaksh wrote: post #4
niutech wrote: post #2

Sadly, still no Framebuffer API for WASI GUI apps ( https://github.com/WebAssembly/WASI/issues/174 ).

I have always suspected that sort of thing is somehow blocked by Google because it would make mean web assembly runtimes don't need web browsers. Although now that there is actually a significant update to WASI, perhaps it's possible that they are just actually that slow? Or maybe both are true. Probably I am just a "conspiracy nut". I mean I definitely am, but in this case it might just be paranoia.

I hope safari implements these things so I could reasonably run a wasm build of firefox on ios

Re: WASI 0.2.0 and Why It Matters

#40

Post by [deleted] »

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…

[deleted]
Post reply on HN