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

WebAssembly: A promising technology that is quietly being enshitified

kerkour.com

Post reply on HN
Print view View original

21–30 of 64 posts

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

#21

Post by kmeisthax »

To be clear, this is (mainly) about the enshittification of WASI, not WASM. If you're writing code to run in a web browser you will never interact with WASI. It is unfortunate to see WASI fall victim to the software componentry / IDL meme, but I doubt we're going to see that be an issue in browser WASM.

The part that actually pertains to WASM - async/await - exists because everything in a browser lives in Someone Else's Single Threaded Event Loop. Writing code that lives in an event loop is pure pain, and async/await exists solely to fix this problem. The billion dollar mistake is not adding async/await to programming languages, it's single-threaded event loops. Anyone talking about C10K or non-blocking I/O in regards to async/await is probably missing the point, because aside from one stubbornly single-threaded programming language[0] you can launch threads to handle reading or writing data and sockets.

[0] JavaScript. It's always JavaScript.

If you were thinking Python, you're wrong. Even with the GIL, Python supports threads, and concurrent I/O is one of the few reasons why they're useful.

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

#22

Post by wrs »

Arnavion wrote: post #19

Components are basically COM / CORBA for WASM. Just like COM enabled multiple languages to exchange structs and function calls with each other, WASM components do the same. The C ABI approach works fine but becomes complicated when you want to pass things that aren't fixed-length, because unlike the C ABI usage when linking different libraries into the same address space, the host and the module run in different addr…

I think the argument here is that you don’t need a full N:1:M mapping of data types to make this work. Transparency is a myth. If you try it (as in Sun RPC, DCE, CORBA, COM, etc.) you end up just writing wrappers anyway as you hit some edge case that the universal type system doesn’t support. E.g., look at the clunky IDL interfaces COM had to invent to get interop with JavaScript objects because IDL had baked-in assumptions about how records work.

Since the point is to enable component-level interop, not fine-grained function interop, you can instead define a simple interchange format (more JSONish than IDLish) and write the library interfaces accordingly. More of a microservice approach than a linker approach.

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

#23

Post by p_l »

Arnavion wrote: post #19

Components are basically COM / CORBA for WASM. Just like COM enabled multiple languages to exchange structs and function calls with each other, WASM components do the same. The C ABI approach works fine but becomes complicated when you want to pass things that aren't fixed-length, because unlike the C ABI usage when linking different libraries into the same address space, the host and the module run in different addr…

Don't forget the extra fun that happens when you call free() from a different allocator than the one that allocated the memory object, though I suspect WASM's module approach might make it difficult to happen...

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

#24

Post by worik »

kmeisthax wrote: post #21

To be clear, this is (mainly) about the enshittification of WASI, not WASM. If you're writing code to run in a web browser you will never interact with WASI. It is unfortunate to see WASI fall victim to the software componentry / IDL meme, but I doubt we're going to see that be an issue in browser WASM. The part that actually pertains to WASM - async/await - exists because everything in a browser lives in Someone Els…

> Writing code that lives in an event loop is pure pain,

Do you think?

I find explicit event loops pleasurable.

Does that make me a freak?

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

#25

Post by Arnavion »

wrs wrote: post #22
Arnavion wrote: post #19

Components are basically COM / CORBA for WASM. Just like COM enabled multiple languages to exchange structs and function calls with each other, WASM components do the same. The C ABI approach works fine but becomes complicated when you want to pass things that aren't fixed-length, because unlike the C ABI usage when linking different libraries into the same address space, the host and the module run in different addr…

I think the argument here is that you don’t need a full N:1:M mapping of data types to make this work. Transparency is a myth. If you try it (as in Sun RPC, DCE, CORBA, COM, etc.) you end up just writing wrappers anyway as you hit some edge case that the universal type system doesn’t support. E.g., look at the clunky IDL interfaces COM had to invent to get interop with JavaScript objects because IDL had baked-in assu…

Counter-point: I happen to be working at $dayjob on things related to Components (both on the host side and the module side), including using some "WIP" things like the "resource" feature (opaque handles with methods), and haven't hit any edge cases.

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

#26

Post by worik »

olsonjeffery wrote: post #10
fathyb wrote: post #6

Earlier quoted context omitted.

> moving between release or debug affects nothing I'd start with that, it's an obvious red flag. Switching between both should create huge differences. Also look into `wasm-opt` from the Binaryen project for post-link optimizations, `wasm-ld` from LLVM isn't that great at DCE.

Thanks for the feedback. I was wrong about debug vs release; It's the difference between 4.0MB & 893KB on a ~500 LOC rust codebase (per cloc). I want to observe that your suggestions don't undermine or refute my point about problems that WASM adoption faces. This serves to underline that the developer experience needs work. Opinions may differ on how much. Also that "developer experience" runs on multiple axes of con…

> 4.0MB & 893KB on a ~500 LOC rust codebase (per cloc).

My guess is 50,000 LOC would not be 100 times bigger err

Methinks you are counting overhead

More accurately... meguess

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

#27

Post by wrs »

Arnavion wrote: post #25
wrs wrote: post #22

Earlier quoted context omitted.

I think the argument here is that you don’t need a full N:1:M mapping of data types to make this work. Transparency is a myth. If you try it (as in Sun RPC, DCE, CORBA, COM, etc.) you end up just writing wrappers anyway as you hit some edge case that the universal type system doesn’t support. E.g., look at the clunky IDL interfaces COM had to invent to get interop with JavaScript objects because IDL had baked-in assu…

Counter-point: I happen to be working at $dayjob on things related to Components (both on the host side and the module side), including using some "WIP" things like the "resource" feature (opaque handles with methods), and haven't hit any edge cases.

Sure, it’s expected that you won’t hit problems if you’re using the paradigms that existed when the IDL was defined. On the other hand, trying to apply Sun RPC after everything became object-oriented…well, that’s when we blew it up and invented CORBA. So I’m just saying the cycle is likely to continue with this approach. In other words, come back in ten years and see how it aged.

The alternative is to use something so simple it can’t become outdated. Dumb down the interface rather than making the interop omniscient. (Kind of like the dumb network principle.)

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

#28

Post by mbStavola »

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

Completely disagree.

Async as a paradigm has probably created billions of dollars in that it's allowed many many many developers to reasonably scale beyond what they could've otherwise.

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

#29

Post by pjmlp »

wrs wrote: post #22
Arnavion wrote: post #19

Components are basically COM / CORBA for WASM. Just like COM enabled multiple languages to exchange structs and function calls with each other, WASM components do the same. The C ABI approach works fine but becomes complicated when you want to pass things that aren't fixed-length, because unlike the C ABI usage when linking different libraries into the same address space, the host and the module run in different addr…

I think the argument here is that you don’t need a full N:1:M mapping of data types to make this work. Transparency is a myth. If you try it (as in Sun RPC, DCE, CORBA, COM, etc.) you end up just writing wrappers anyway as you hit some edge case that the universal type system doesn’t support. E.g., look at the clunky IDL interfaces COM had to invent to get interop with JavaScript objects because IDL had baked-in assu…

Or COM's evolution, WinRT, where the .NET metadata also doesn't really map to JavaScript or C++, without some additional kludges with metadata as workaround.

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

#30

Post by pjmlp »

kmeisthax wrote: post #21

To be clear, this is (mainly) about the enshittification of WASI, not WASM. If you're writing code to run in a web browser you will never interact with WASI. It is unfortunate to see WASI fall victim to the software componentry / IDL meme, but I doubt we're going to see that be an issue in browser WASM. The part that actually pertains to WASM - async/await - exists because everything in a browser lives in Someone Els…

You definitely will, because this is the approach that is also being taken by runtimes like Dart, Kotlin among others.
Post reply on HN