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

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

#31

Post by Arnavion » Wed, May 22, 2024, 7:54 PM UTC

fathyb wrote: post #15

olsonjeffery wrote: post #12

Earlier quoted context omitted.

I don't think there's any guarantee that browser vendors will continue to support WASI 0.1 indefinitely; Once multiple versions of the standard are in play, codebase supporting them simultaneously explode in size. None of this gets into the likelihood that, once WASI hits 1.0, the prior versions very well could be "retired". And keep in mind that the perspective of the author is that things will only get worse from h…

I didn't know browser vendors supported WASI! I said that as some of us do not use WASI at all, just WebAssembly itself, so they can save some time by not reading this if they're not interested in WASI and/or its limitations.

Browsers don't have any built-in support for WASI. It's up to the web page to define those as exports for WASI-expecting WASM modules to import.

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

#32

Post by coxley » Wed, May 22, 2024, 7:54 PM UTC

worik wrote: post #24

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?

They're pleasurable when you're the only author. They become a minefield unless every contributor is diligent, which happens very often.

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

#33

Post by wrs » Wed, May 22, 2024, 7:57 PM UTC

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…

I just realized: The very fact that WASI isn’t using any of the previous N attempts at a supposedly universal IDL, but instead inventing yet another one, itself demonstrates the problem with this approach.

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

#34

Post by superchris » Wed, May 22, 2024, 7:59 PM UTC

The promise of being able to use any library from any language is really quite compelling, and that's what the WASM component model is about for me. It's pretty sad to say this amount of hate TBH

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

#35

Post by Arnavion » Wed, May 22, 2024, 8:02 PM UTC

p_l wrote: post #23

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...

Yes, that won't happen here, because the host is just calling some global malloc and free exported by the module. Well, obviously the implementations of those globals can be buggy in some way, but that's the module's bad.

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

#36

Post by amw-zero » Wed, May 22, 2024, 8:02 PM UTC

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

What does this even mean, how can you do any form of modern computation without async?

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

#37

Post by shanemhansen » Wed, May 22, 2024, 8:12 PM UTC

> You have been blocked! If you are not a malicious actor, please update your web browser to the latest version to access this website. If the problem persists, please contact support.

Unfortunate.

I think that these days the scammers have won. They can do a better job than I can at being authentic.

FWIW based on the comments I actually prefer a richer runtime that allows some of the language level features that have been hard to get support for. I think having mainstream support for effects would be sort of magical.

Actual isolated modules? Talk about living in the future.

Wasm is a lot like the jvm and flash, which makes some people hate it. But for me the problem with those platforms was the execution, not the idea.

I'm cautiously optimistic that wasm will finally give us a good high performance cross platform secure execution target for the web.

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

#38

Post by anakaine » Wed, May 22, 2024, 8:16 PM UTC

mbStavola wrote: post #28

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.

Agree wholesale. I've got a complex data reader built on a single server that receives tens of thousands of requests a day, and most tend to happen in a few hour window. Async was super important to scale to user requests by allowing non-blocking calls to not get captured behind blocking ones.

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

#39

Post by torginus » Wed, May 22, 2024, 8:16 PM UTC

pjmlp wrote: post #7

You have been blocked, apparently Android Chrome is a malicious browser.

Probably they are blocking access from 'suspicious places' e.g. anywhere that's not the US or Western Europe.

The irony of talking about enshittification...

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

#40

Post by prerok » Wed, May 22, 2024, 8:17 PM UTC

mbStavola wrote: post #28

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.

And I disagree with your disagreement :)

Just some background first: one of the billion dollar mistakes is the null pointer which is a special value to be assigned to any type. It was inherent in the first high (today considered low) level languages. Those languages (C most importantly, then Java and nowadays even Go) enabled many more programmers to create programs and they likely would not have been able to, had they been forced to write assembly. So, it's a billion dollar mistake within a trillion dollar revenue.

The async now solves a similar practical problem but in the space of prallelism (or concurrency, in some cases). A different approach might have given us the same result, but a different implementation that might be just as approachable.

Optionals and Results have given us a better way than to have nulls, and maybe golang style channels could have given us a better way to handle async?