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

WebAssembly’s post-MVP future

hacks.mozilla.org

Post reply on HN
Print view View original

81–90 of 207 posts

Re: WebAssembly’s post-MVP future

#81

Post by amelius »

rkangel wrote: post #73
amelius wrote: post #52

Earlier quoted context omitted.

Why not implement the GCs themselves using low-level WASM code? That would enable a language-agnostic approach (though it would prohibit collecting garbage over multiple cooperating languages at the same time, which is a less urgent problem imho).

You've already got 2 co-operating languages - JS and whatever is compiler to WASM.

True, but once you're using WASM, you probably don't need to hold references to JS objects that point back to the objects created in WASM.

We've been interfacing C with e.g. Python without needing a garbage collector that crosses language boundaries. So why would we need one now?

Re: WebAssembly’s post-MVP future

#82

Post by matthberg »

The parallels with the Destroy All Software talk "The Birth and Death of Javascript" [0] are crazy. Seeing the section where they address the possibility of Node modules and system access from WASM is like seeing a flying car advertisement in real life.

[0]:https://www.destroyallsoftware.com/talks/the-birth-and-death...

Re: WebAssembly’s post-MVP future

#83

Post by chriswarbo »

tyingq wrote: post #56
zimbatm wrote: post #49

I'm a bit concerned by the addition of Garbage Collection to WASM. Is there a way to implement those without favouring some type of language? It seems to me that GC tuning and memory models are very language-specific. A purely-functional language like Haskell or Closure can make different assumptions about the memory regions but also generate a lot more young generation items compared to OOP languages.

The CLR in .Net seems to support a very broad spectrum of languages, including functional, statically typed, dynamically typed, etc.

I've not used the CLR, but the one thing I noted in Gilad Bracha's recent post on generics ( https://gbracha.blogspot.com/2018/10/reified-generics-search... ) was his claim that the CLR makes implementing and using dynamic languages difficult:

> In systems designed to support multiple programming languages, reification brings a different problem. All languages must deal with the complexity of reification; worse they must conform to the expectations of the reified generic type system of the "master language" (C# or Java, for example).

> Consider .Net, the poster child of generic reification. Originally, .Net was intended to be a multi-language system, but dynamic language support there has suffered, in no small part due to reification. Visual Basic was a huge success until .Net came along and made it conform to C#. And what Iron Ruby/Python programmer ever enjoyed being forced to feed type arguments (whatever those might be) into a collection they are creating?

Not saying CLR's approach is bad; just that it doesn't seem like an example of one-size-fits-all as is sometimes claimed (and the same goes for the JVM, etc. too)

Re: WebAssembly’s post-MVP future

#84

Post by Game_Ender »

kodablah wrote: post #2

Here's a newly created proposals repo to keep track: https://github.com/WebAssembly/proposals . > Skill: 64-bit addressing As a WASM backend implementer in an environment w/ only 32-bit addresses, I hope people don't move to 64-bit addresses too soon. Are we really reaching the limits here already? > Skill: Portability [...] A POSIX for WebAssembly if you will. A PWSIX? A portable WebAssembly system interface. Yes pl…

64 bit addressed cannot come soon enough. In certain domains the entire data set you want to work with is many times the 4GB limit, and JS has no such restriction so it’s a PITA that WASM does.

Re: WebAssembly’s post-MVP future

#85

Post by TomMarius »

amelius wrote: post #52
zimbatm wrote: post #49

I'm a bit concerned by the addition of Garbage Collection to WASM. Is there a way to implement those without favouring some type of language? It seems to me that GC tuning and memory models are very language-specific. A purely-functional language like Haskell or Closure can make different assumptions about the memory regions but also generate a lot more young generation items compared to OOP languages.

Why not implement the GCs themselves using low-level WASM code? That would enable a language-agnostic approach (though it would prohibit collecting garbage over multiple cooperating languages at the same time, which is a less urgent problem imho).

> (though it would prohibit collecting garbage over multiple cooperating languages at the same time, which is a less urgent problem imho).

That's the whole reason they're adding a GC, how is it not an urgent problem?

Re: WebAssembly’s post-MVP future

#86

Post by TomMarius »

amelius wrote: post #81
rkangel wrote: post #73

Earlier quoted context omitted.

You've already got 2 co-operating languages - JS and whatever is compiler to WASM.

True, but once you're using WASM, you probably don't need to hold references to JS objects that point back to the objects created in WASM. We've been interfacing C with e.g. Python without needing a garbage collector that crosses language boundaries. So why would we need one now?

Because that's not safe. It's only as safe as the Python binding is, which is not good enough.

Re: WebAssembly’s post-MVP future

#87

Post by ecnahc515 »

kodablah wrote: post #25
jholman wrote: post #17

Okay, I've only done the over-breakfast skim of this, and I hate to be that guy who comments without having fully read TFA, but here I go anyway... I don't see any explicit mention of what I understand to be the killer feature: the ability to directly access the browser's WebAPIs, from Accelerometer to Document to MimeType to XPathExpression. Start with modifying the DOM, and go from there. Of course fast WASM/JS int…

What is the meaningful difference between WASM/JS interop and WASM/Web-API interop? Implicit importing of them all? There are host bindings coming [0]. If Web APIs are expressed in terms of JS and you want interop with them, you use what they are expressed in. Or are you saying Web APIs should be available in WASM terms (which is harder due to lack of structural, array, string, null, etc types)? 0 - https://github.co…

It would kind of be like defining a set of syscalls that anything targeting WASM could use. Right now, JS interop is sorta like being given a DLL that requires an entire JS runtime to support it, whereas direct Web-API interop would mean there is no JS runtime requirement IIRC.

Re: WebAssembly’s post-MVP future

#88

Post by amelius »

TomMarius wrote: post #86
amelius wrote: post #81

Earlier quoted context omitted.

True, but once you're using WASM, you probably don't need to hold references to JS objects that point back to the objects created in WASM. We've been interfacing C with e.g. Python without needing a garbage collector that crosses language boundaries. So why would we need one now?

Because that's not safe. It's only as safe as the Python binding is, which is not good enough.

Define "safe". Are you talking about security or correctness, or both, and please elaborate.

Re: WebAssembly’s post-MVP future

#90

Post by TomMarius »

amelius wrote: post #88
TomMarius wrote: post #86

Earlier quoted context omitted.

Because that's not safe. It's only as safe as the Python binding is, which is not good enough.

Define "safe". Are you talking about security or correctness, or both, and please elaborate.

The point of WASM is the ability to safely run any untrusted code in a performant way, that includes seamless interfacing with other modules.

https://webassembly.org/docs/security/

Post reply on HN