Hacker News new | ask | show | jobs
by pjmlp 1518 days ago
Flash, Silverlight, Java, TinyGo and .NET are doing just fine on WebAssembly.
2 comments

In isolation, but no cross-language invocations, reference sharing etc yet.

It'll work as promised when I can import a C# class in my JS code, instantiate it and then pass one of its methods to a Python module and invoke it from there.

Great times are ahead of us.

You mean like using JScript alongside C# and IronPython on the CLR, ah the circles of rediscovery.
Exactly like that, but also in a secure sandbox and in the browser. Can CLR do that without Wasm?
In the browser, that is what Silverlight was all about.

Outside of the browser, WebAssembly is still a shadow of CLR capabilities, including sandboxing.

As for the "secure" in WebAssembly, I advise a good read about the security section, specially memory corruption

https://webassembly.org/docs/security

https://www.unibw.de/patch/papers/usenixsecurity20-wasm.pdf

Silverlight never had even the slightest hint of security, and no interop with JS or non-CLR (e.g. JVM) languages.

It was also comically slow and worked only in IE.

I'm well versed in security of Wasm. Much better than anything else available today or in the past, obviously still not perfect.

One of the best features of Wasm is entirely social - seems like everyone has agreed on it, finally. That's enough for me even if it was a 1:1 copy of JVM or CLR.

The new NoSQL and big data hype of bytecode based runtimes.
Supporting GC on WebAssembly has been a _major_ pain for TinyGo because WebAssembly doesn't allow access to the stack. It's really slow and I'm still not confident it's bug free. Having a GC integrated in WebAssembly itself should solve these issues.

Unfortunately, the current GC design for WebAssembly doesn't support interior pointers which is going to be difficult to work around (but I don't think it's impossible). Interior pointers are normally required in Go.