WebAssembly: A promising technology that is quietly being enshitified • Hacker News Board

Re: WebAssembly: A promising technology that is quietly being enshitified

#61

Post by leucippe » Fri, May 24, 2024, 6:37 AM UTC

aixpert wrote: post #51

worik wrote: post #18

OT but this... > I strongly believe that async is the new billion dollar mistake of the 2020's: a design aberration that wasted so much developers time that it had cost billions of dollars to companies. Yes. Nicely put

Wait they promised to not adopt the cancerous function coloring approach in wasm. Please tell me they didn't follow the dark path of JS

The plan is to support async without function colouring.

I recommend this talk by Luke Wagner on async plans in WASI 0.3 (https://youtu.be/y3x4-nQeXxc) for background on how it will work.

To summarise, from an API perspective, the caller and callee won't know if the other is async or not. When calling async from non-async, an event loop is inserted at link-time and it blocks.* When calling non-async from async, the callee will get suspended if it tries to do blocking IO. That still leaves the problem of long-running compute without IO in a non-async context, but at least you're not wasting CPU time in that scenario.

* If the host runtime already has an event loop, I assume the callee will get added to that.

Re: WebAssembly: A promising technology that is quietly being enshitified

#62

Post by leucippe » Fri, May 24, 2024, 1:52 PM UTC

10000truths wrote: post #17

olsonjeffery wrote: post #2

It's hard because, a lot of this stuff (async WASM, effect-driven WASM, GC in WASM, etc) is all driven by the desire to push these concerns out of wasm bytecodes, because it explodes the binary's size . I have a pretty trivial webapp written in Yew and I stopped working on it once I saw that the wasm artifacts were weighing at 4MB (uncompressed) for relatively little functionality. THIS is what is driving the next ro…

Then maybe "this stuff" should not have been tacked onto the WASM standard in the first place? There's no free lunch. Sure, it sucks that your favorite garbage-collected interpreter/runtime bloats your module size. But the alternative option is to bloat every WASM engine by shoehorning your use case into the standard.

As much as binary size should be a problem for individual developers to deal with, I've seen how those individual developers treat Electron. There's no doubt in my mind that someone will ship 50 little JavaScript programs inside wasm modules, each with its own garbage collector. Then it becomes my problem.

Promise you won't tell the GC'd language enthusiasts this, but wasm engines supporting the wasm-gc proposal don't need to ever run a garbage collector. A simple bump allocator is 100% compliant, as long as the module's memory gets cleaned up once it terminates. Wasm engines for embedded systems will probably do exactly that, and leak memory rather than collect garbage. The web already has a garbage collector for JS, so not a big deal there either. Bloat has its cost, but at least it's only paid by cloud/edge/desktop and other use-cases that can afford to put it in their engine.

I think wasm-gc is worth it for WebAssembly. The dream is "run any language, anywhere" but it's always been easier for low level languages like C, C++ and Rust, because their binaries are smaller. Maybe with things like wasm-gc, WebAssembly can be great for C, C++, Rust, but also JavaScript and Python, Java and Go, OCaml, Perl, and whatever language gets sprung on us next.

Re: WebAssembly: A promising technology that is quietly being enshitified

#63

Post by worik » Fri, May 24, 2024, 10:35 PM UTC

amw-zero wrote: post #45

MrDarcy wrote: post #41

Earlier quoted context omitted.

async / await as they exist in JavaScript, Python, and Rust aren’t the only way to execute tasks concurrently.

That’s what I’m asking - did the comment mean that the async/await pattern is bad, or that asynchronous programming in general is bad?

asynchronous programming is the bee's knees, and my preferred mode

Asyc/await pretends to be synchronous and gets all tied in horrible knots when the sunk costs mount

Writing IO without blocking has always been second nature to me

Re: WebAssembly: A promising technology that is quietly being enshitified

#64

Post by worik » Fri, May 24, 2024, 10:36 PM UTC

eureka-belief wrote: post #56

MrDarcy wrote: post #41

Earlier quoted context omitted.

async / await as they exist in JavaScript, Python, and Rust aren’t the only way to execute tasks concurrently.

But they are a darn convenient mental model if you’re just trying to do some basic async. The alternatives are harder to wrap your head around. Unless I’m missing some other cool pattern.

> Unless I’m missing some other cool pattern.

Explicit state machines