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

91–100 of 103 posts

Re: WASI 0.3

#91

Post by b33j0r »

hectaman wrote: post #26
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…

I don't think it's fair to say this work has happened in the shadows. I work on CNCF wasmCloud, and I know how hard we try to make this content available. - Many standing meetings organized around SIGs, all on the public community calendar: https://calendar.google.com/calendar/u/0/newembed?src=events... - A dedicated Zulip: https://bytecodealliance.zulipchat.com/ - Conferences organized around exactly these topics: W…

It was not fair. It was how I felt trying to build on it. I love the content that was produced, but it was all very experimental and garden shedded from a decision-making angle.

To answer directly, I would credit the PSF and python community with having the best structure that has outlasted my weirdest expectations.

Re: WASI 0.3

#92

Post by garganzol »

pie_flavor wrote: post #55
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 present component model is "simple and stable". It is presently providing "interoperability between different ecosystems" and has been for years. It has basically nothing in common with CORBA. All the major problems with the Unix design they ran into that caused them to switch to a component model haven't vanished; the component model is still the best way of solving WASM's major complications that traditional C-…

WASM component model is internal to the WASM project, isn't it? As such, it provides interoperability for one and only ecosystem (WASM), and thus has no chances to be perceived worthy and universal enough for people to care, that's the point.

Re: WASI 0.3

#93

Post by garganzol »

0x457 wrote: post #52
tete wrote: post #34

Earlier quoted context omitted.

I agree. This is saddening. It seems to often happen in "standard first" scenarios for some reason. I was very happy when CloudABI and POSIX were picked as prior art inspiration. Now it feels like it moved from "what would we need to get things done and achieve our goals?" to "what could be done and which goals could we achieve?" Maybe I am missing something, but are the recent changes something that people requested…

Yes, you missed people asking for years: away to do interop between languages in WASM, a way to interact with browser APIs without JavaScript from WASM. Component model enable both using one thing.

> way to do interop between languages

This problem stems from the lack of a standardized component model. WASM is merely another casualty of that deficiency - one among hundreds of affected technologies.

The alliance is attempting to solve the problem at the wrong level and only for WASM, rather than addressing the root cause in a way that would benefit everyone.

Re: WASI 0.3

#94

Post by xyzzy_plugh »

himata4113 wrote: post #87
derefr wrote: post #68

Earlier quoted context omitted.

> The promise of wasi components has not been fulfilled. The market wants to hotload and link artifacts dynamically. The wasi project requires insider wizardry to use it that way: the offering has been statically linking components before you ship. Defeating 99% of the use cases. I think both of these points on the spectrum (on the one end, fully static linking of WASI components within a monolithic single-source pro…

I do specifically that and abandoned WASI in favor of freestanding with shared memory regions + PIC memory region. It works today and is easily extensible as well as increadibly fast, sandboxing is not as strong since modules can read code they don't own and modify data they do not own, but splitting modules into "trusted" and "untrusted" largely mitigated those issues as memory has write bit stripped for execution d…

> Point being, if you rely on a non standard specification of developer defined wasi api subspec you might as well just go with freestanding.

Precisely this. The whole endeavor has been disappointing. I'd love to build support for WASI but realistically it's far simpler for all parties just to do something custom, which feels wrong. I get that it's only 0.3 but it's advancing far too slowly for my tastes. I just don't know who it's for right now.

Re: WASI 0.3

#95

Post by lifthrasiir »

panick21_ wrote: post #90
lifthrasiir wrote: post #86

Earlier quoted context omitted.

I have seriously attempted to write my own WebAssembly 3.0 implementation recently, and while I did finish the whole thing [1] that left me a bitter taste about WasmGC which turned out to be very annoying to implement. In fact, I originally wanted to avoid GC but spectest assumed that GC is always available and I had no other option but implementing one in order to make use of spectest in the first place. [1] https:/…

Interfacing with GC is usually hard, how should have it been done?

Of course, but I'm talking about "annoyance". GC type system is especially annoying if you are not writing the full compiler.

Re: WASI 0.3

#96

Post by pie_flavor »

garganzol wrote: post #92
pie_flavor wrote: post #55

Earlier quoted context omitted.

The present component model is "simple and stable". It is presently providing "interoperability between different ecosystems" and has been for years. It has basically nothing in common with CORBA. All the major problems with the Unix design they ran into that caused them to switch to a component model haven't vanished; the component model is still the best way of solving WASM's major complications that traditional C-…

WASM component model is internal to the WASM project, isn't it? As such, it provides interoperability for one and only ecosystem (WASM), and thus has no chances to be perceived worthy and universal enough for people to care, that's the point.

What are you talking about? The point of WASI is to stabilize WASM's access to OS APIs. It uses the component model to do this, which is bound to by languages that compile to WASM and by runtimes that run WASM. That is the only kind of interoperability that is required for this WASM system for WASM components to do WASM things.

Re: WASI 0.3

#97

Post by artemonster »

tdhz77 wrote: post #20
artemonster wrote: post #8

Earlier quoted context omitted.

for me its undebuggability. -"hey, look at our C Rust FORTRAN to WASM translator, blahblah" -"uhm, cool, how do I debug it?" -"yeah...about that...you cant!"

Why can’t you?

how can you? its running wasm in a browser, how do you see original C/Rust code and or variables

Re: WASI 0.3

#98

Post by artemonster »

phickey wrote: post #69
artemonster wrote: post #8

Earlier quoted context omitted.

for me its undebuggability. -"hey, look at our C Rust FORTRAN to WASM translator, blahblah" -"uhm, cool, how do I debug it?" -"yeah...about that...you cant!"

Wasmtime implements a remote debugging server, so that you can debug guest programs with a recent build of LLDB. Set breakpoints based on the source language symbols, single-step through wasm opcodes, anything you'd expect: https://docs.wasmtime.dev/examples-debugging-guest.html

still useless. I had an idea to offload parts of my game core into wasm leaving only UI in the browser - I abandoned that idea when there was absolutely zero possibility for me to debug in browser what is wrong with my core. i just rewrote everything to TS (from rust)

Re: WASI 0.3

#100

Post by hectaman »

b33j0r wrote: post #91
hectaman wrote: post #26

Earlier quoted context omitted.

I don't think it's fair to say this work has happened in the shadows. I work on CNCF wasmCloud, and I know how hard we try to make this content available. - Many standing meetings organized around SIGs, all on the public community calendar: https://calendar.google.com/calendar/u/0/newembed?src=events... - A dedicated Zulip: https://bytecodealliance.zulipchat.com/ - Conferences organized around exactly these topics: W…

It was not fair. It was how I felt trying to build on it. I love the content that was produced, but it was all very experimental and garden shedded from a decision-making angle. To answer directly, I would credit the PSF and python community with having the best structure that has outlasted my weirdest expectations.

Yeah, I feel that - everything was so green in the beginning that getting a Hello World together was painful. When I started, I was still at a big bank, and there wasn't even an IDL selected, so we just started building with SMITHY. Then adopting WIT, etc...

I would say now, especially with AI and Rust, it is night and day. I think as folks come to the conclusion that they care more about what gets built than the how it is done, they start to feel the need for a sandbox. So, WASI P3 is coming along at a really fortunate time. I haven't had any issue nearly oneshotting things directly into wasm with claude.

I appreciate the suggestion on good communities doing it well.

Post reply on HN