Rust and WebAssembly in 2019

Post by [deleted] » Sun, Dec 16, 2018, 5:06 AM UTC

steveklabnik wrote: post #18

losvedir wrote: post #10

It didn't click until just now that rust is very naturally suited to WebAssembly due to its lack of garbage collection. As I understand it, there's no current plans for WebAssembly to include a garbage collector, so higher level languages that want to compile to it will need to bundle their own, increasing the size of the download quite a bit.

Yep! This is a key insight. Even beyond that, there are two approaches you can take: writing your app in wasm, or writing libraries in wasm. Languages with larger runtimes may work for apps, but you don’t want to use them for libraries, because then you lug around every runtime for every language used. Even once wasm can integrate with the host’s GC, non-GC’d languages will have a place in implementing core libraries…

Post by PaulBGD_ » Sun, Dec 16, 2018, 6:03 AM UTC

swsieber wrote: post #42

xvilka wrote: post #39

Until there is direct DOM access within WebAssembly, the overhead of calling back and forth to JS will prevent wider adoption and ditching JS for Web development.

That overhead has been greatly reduced in Firefox recently.

Post by [deleted] » Sun, Dec 16, 2018, 6:16 AM UTC

archgoon wrote: post #44

shmerl wrote: post #31

Can WebAssembly be used without any JavaScript? Or JavaScript is always required in some combination with it?

It cannot be used without javascript because it currently has no interface to the DOM. Without DOM access, you're simply running a virtual machine isolated from everything else, and that would serve no purpose aside from burning clock cycles :). It is currently felt that Webassembly shouldn't be given access to the DOM until after a garbage collection interface is created. Until that happens, any object given to the…

Post by steveklabnik » Sun, Dec 16, 2018, 6:26 AM UTC

whateveracct wrote: post #30

steveklabnik wrote: post #18

Earlier quoted context omitted.

Yep! This is a key insight. Even beyond that, there are two approaches you can take: writing your app in wasm, or writing libraries in wasm. Languages with larger runtimes may work for apps, but you don’t want to use them for libraries, because then you lug around every runtime for every language used. Even once wasm can integrate with the host’s GC, non-GC’d languages will have a place in implementing core libraries…

This only applies to libraries served from separate locations though, right? No issue writing a Haskell library for wasm and then having consumers compile their app leveraging your library (at which point it's bundled with the RTS)

Post by steveklabnik » Sun, Dec 16, 2018, 6:38 AM UTC

hu3 wrote: post #26

azangru wrote: post #15

Earlier quoted context omitted.

> As I understand it, there's no current plans for WebAssembly to include a garbage collector There are plans to add a garbage collector. See https://hacks.mozilla.org/2018/10/webassemblys-post-mvp-futu... . But meanwhile, Webassembly is mainly just for C and Rust.

> Webassembly is mainly just for C and Rust That's absolutely incorrect. Go and .NET can target WASM for quite a while now. Microsoft's Blazor is specially interesting. Their FlightFinder demo written in pure C# renders a beautiful app: https://i.imgur.com/HHFkB1E.png Code here: https://github.com/aspnet/samples/tree/master/samples/aspnet...