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

WASI 0.3

bytecodealliance.org

Post reply on HN
Print view View original

41–50 of 103 posts

Re: WASI 0.3

#41

Post by throawayonthe »

Dwedit wrote: post #25
shevy-java wrote: post #2

Will WebAssembly ever achieve a real breakthrough? It's been almost 10 years since it came around. HTML, CSS and JavaScript were a breakthrough back in the days. WebAssembly still is not right now; only very few folks or companies use it.

WebAssembly doesn't beat JavaScript in performance, and that is embarrassing.

it is faster, but there is unacceptable loss when passing data to/from js, definitely an area needing improvement (or having to do it less)

https://hacks.mozilla.org/2026/02/making-webassembly-a-first...

Re: WASI 0.3

#42

Post by spankalee »

lifty wrote: post #12

If you have used WASI in the past, can you mention your use case? Very curious if you found it to give you an edge compared to other sandboxing like containers or VMs.

I'm using it for a secure, language agnostic workflow orchestrator. Components have very finely-grained and controller permissions and access to data. They don't even get clocks by default (to mitigate against Spectre-style attacks) and credentials and tainted data are sequestered.

Re: WASI 0.3

#43

Post by spankalee »

b33j0r wrote: post #11

Love/hate with this one. How was I supposed to follow this? I tried, and few things were publicly visible for nearly two years. I last checked in march and it looked like no progress had been made. That makes me very suspicious of wasiv3. Funny enough, I already implemented a bunch of the promises (pun not intended) and think that freestanding wasm with custom integrations is the more likely future. The promise of wa…

There is an issue open for instantiating modules at runtime: https://github.com/WebAssembly/component-model/issues/423

Re: WASI 0.3

#44

Post by zozbot234 »

garganzol wrote: post #18

Wrong direction. WASI should be simple and stable. Initially, it was revolving around a simple Unix-like API model and it was close to perfect. Now, there is an opinionated component model which is an unneeded overcomplication that should have never been considered as part of WebAssembly spec IMHO. A real component model is a separate development and cannot be blindly tied to a particular ecosystem. Otherwise, its ma…

AIUI, the underlying motivation for the WASM component model is the same as for the early interface types proposal, which has been a planned part of WASM since the very beginning - namely to allow modules written in high-level languages to expose "native" interfaces, without requiring a completely bespoke translation into WASM's lower level facilities. That's a sensible goal, even if achieving this may ultimately involve something that's at least loosely reminiscent of CORBA.

Re: WASI 0.3

#45

Post by Ericson2314 »

iqihs wrote: post #38
IshKebab wrote: post #32

Earlier quoted context omitted.

I disagree. We shouldn't just be copying Unix until the end of time.

less copying and more keeping in the spirit of, as it has clearly shown it is a model that is built to last

That's like saying "the US Constitution has clearly shown it's a model that is built to last"

Sometimes bad designs stick around due to pure inertia

Re: WASI 0.3

#46

Post by lenkite »

spankalee wrote: post #39
garganzol wrote: post #18

Wrong direction. WASI should be simple and stable. Initially, it was revolving around a simple Unix-like API model and it was close to perfect. Now, there is an opinionated component model which is an unneeded overcomplication that should have never been considered as part of WebAssembly spec IMHO. A real component model is a separate development and cannot be blindly tied to a particular ecosystem. Otherwise, its ma…

The component model is what unlocks relatively type-safe interop between modules written in different languages. Given that Wasm is a runtime target for many languages, this is an entirely appropriate and useful goal. If you have a host system where you want to expose APIs in an language-agnostic way, IDLs are the best way to do that. You're also conflating the core WebAssembly work with the WASI work. There is some…

Why was the component model not expressed in LISP syntax like the way WAT is ? Why have yet another custom IDL language with bespoke parsing rules ?

Re: WASI 0.3

#47

Post by fragmede »

throawayonthe wrote: post #35
garganzol wrote: post #18

Wrong direction. WASI should be simple and stable. Initially, it was revolving around a simple Unix-like API model and it was close to perfect. Now, there is an opinionated component model which is an unneeded overcomplication that should have never been considered as part of WebAssembly spec IMHO. A real component model is a separate development and cannot be blindly tied to a particular ecosystem. Otherwise, its ma…

i don't think people calling it CORBA-like are doing it in good faith, but regardless, no we should not do unix apis everywhere for the rest of time please

what would you have it look like?

Re: WASI 0.3

#48

Post by tete »

IshKebab wrote: post #32
garganzol wrote: post #18

Wrong direction. WASI should be simple and stable. Initially, it was revolving around a simple Unix-like API model and it was close to perfect. Now, there is an opinionated component model which is an unneeded overcomplication that should have never been considered as part of WebAssembly spec IMHO. A real component model is a separate development and cannot be blindly tied to a particular ecosystem. Otherwise, its ma…

I disagree. We shouldn't just be copying Unix until the end of time.

I think there is a difference between "just copying" and "building upon understood systems and standards".

Also to be fair "just copying" works really really well, especially for standards. The primary goal of standardization is not to invent something new, but to have a target that isn't constantly moving.

If you want to build something new and better do that, and if you are ready to build a standard based of it which is very valid. You can also build them together, and CloudABI which they mention as inspiration in their readme for example did it that way. All valid paths.

But you want to start out simple and something common so that people that make use of the standard have an easy time to implement it. After all having more than one implementation is why you need a standard. Otherwise it's maybe a specification, which again, fair enough.

I can stand behind not copying Unix until the end of time, but "Unix" is a common target that people know how to implement and use. And while not even the authors of Unix claim it's great or even good it is something that people already implement (often enough even when not targeting anything unixy at all) so if your goal is to create a standard that those people can target then abandoning that does seem like a wrong move.

Re: WASI 0.3

#49

Post by Dwedit »

kettlecorn wrote: post #29
Dwedit wrote: post #25

Earlier quoted context omitted.

WebAssembly doesn't beat JavaScript in performance, and that is embarrassing.

That's not accurate. I Googled for a recent performance benchmark and found this which indicates Wasm offers a notable performance gain: https://medium.com/@hashbyt/webassembly-vs-javascript-perfor...

My task in question was a number crunching task, basically doing multiply-and-add for 336-bit integers. I wrote a JS version, and a C version compiled into WASM by using Zig. You'd think that WebAssembly would trounce JS here, but it actually didn't.

The JS code had been written carefully to avoid allocations, and also avoiding the built-in JavaScript BigInt. I rolled my own BigInt instead using an array of numbers. Each number, despite being a double, was basically a 48-bit integer. Long multiplication requires splitting a 48-bit integer into two 24-bit integers so an intermediate multiplication result will fit in 48 bits.

The C version used 32x32=64-bit integer math. (Would have been nice if WASM had supported 64x64=128-bit multiplication)

Even with the overhead of using doubles instead of integers, the JavaScript and C versions ran at nearly the same speed. I think the C version was slightly faster, but not significantly. The C version took a lot longer to load, as it had to instantiate a Webassembly object, and had to run glue code to copy things in and out of Webassembly memory.

Re: WASI 0.3

#50

Post by phickey »

lenkite wrote: post #46
spankalee wrote: post #39

Earlier quoted context omitted.

The component model is what unlocks relatively type-safe interop between modules written in different languages. Given that Wasm is a runtime target for many languages, this is an entirely appropriate and useful goal. If you have a host system where you want to expose APIs in an language-agnostic way, IDLs are the best way to do that. You're also conflating the core WebAssembly work with the WASI work. There is some…

Why was the component model not expressed in LISP syntax like the way WAT is ? Why have yet another custom IDL language with bespoke parsing rules ?

There is a wat (s expression) syntax for the component model. The problem with the wat syntax for both Wasm and the component model is they’re a reflection of a binary format, and therefore are terrible for writing by hand. They’re designed to be written by tools, and the text format is just to help you understand the binary format.

I’ve written Wasm and component model wat extensively over the last decade to develop tests for Wasmtime, and even for an expert it’s a bad experience.

Wit syntax is easy to read and write by hand. There are high quality parsers that can transform it to and from the binary or wat format as needed, and code generators for a wide range of languages. It’s a way, way better experience in every way to deal with wit compared to the wat format.

Post reply on HN