Live data from Hacker News

Rust and WebAssembly in 2019

fitzgeraldnick.com

61–70 of 97 posts

Re: Rust and WebAssembly in 2019

#61

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.

There are plans to get garbage collection support into WASM, but GC is already possible, just not native.

In my opinion the major benefit of WASM over Javascript is that it allows different runtimes to be used in browsers.

Python for example has the pyodide project, which works quite well. But its download sizes are totally ridiculous. Which may not matter for certain applications, and even then, there should be a way to host and cache such runtimes for multiple applications or websites.

Re: Rust and WebAssembly in 2019

#62
post #26

Earlier quoted context omitted.

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

This is literally true, but last I checked, Go’s minimum size was about a megabyte, Blazor’s was 300k, and Rust’s is ~100 bytes. That’s what your parent means.

That's only a problem for more traditional websites. For applications 1MB is just not an issue.

I imagine there will be some kind of CDN/cache to distribute runtimes. Maybe even a WASM package management system for browsers?

Re: Rust and WebAssembly in 2019

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

As far as I have understood it, interfacing with JS is quite efficient now. DOM access isn't that bad either.

Re: Rust and WebAssembly in 2019

#64

Earlier quoted context omitted.

This is literally true, but last I checked, Go’s minimum size was about a megabyte, Blazor’s was 300k, and Rust’s is ~100 bytes. That’s what your parent means.

That's only a problem for more traditional websites. For applications 1MB is just not an issue. I imagine there will be some kind of CDN/cache to distribute runtimes. Maybe even a WASM package management system for browsers?

As I said above, this is true for an app, but you wouldn’t want it for every library. That adds up very quick.

A CDN may happen; there’s some details that make it tough. We’ll see.

npm is already that package manager :)

Re: Rust and WebAssembly in 2019

#65
I decided that Rust is the natural next step for my personal side project stuff, which I want to be more on the browser-based gamedev side of things.

The learning curve is enormous - since coming from like Unity and Flash, so much is done for you... I mean, one _can_ write their own shader code and physics and things, but it's not at all required in order to make impressive content. Even in JS, Three.JS and friends typically take care of the heavy lifting and deciding to get closer to the metal on both fronts (CPU and GPU)- and in a new language (for me), is a bit daunting.

Anyway - I figured a good way to push myself to learn more productively is to livestream while I'm coding and figuring stuff out. Forces some accountability and might help others too.

So far I've only done two sessions and about to do my third. The goal is to build a WebGL renderer from scratch with nothing but Rust (I had a Typescript project that was after the same goal - so there's going to be a fair amount of straight conversion, but it was never totally finished and some things can be improved even if they would theoretically translate 1:1)

Live Stream URL: https://www.youtube.com/channel/UCGKhwtFOUlzj4VILDU0efkQ/liv...

Playlist URL: https://www.youtube.com/playlist?list=PLkzdeKCVtKYshqmgngLSq...

If you join, please remember - the whole point is that I don't know what I'm doing (yet) and I actually _want_ to struggle in order to learn, rather than have solutions spoon-fed to me.

I think there will ultimately be at the very least some general functions here which can be useful abstractions over web_sys/js_sys/etc. At least I hope so!

Lastly - schedule is irregular, so best way to know when it's live is to subscribe and rely on youtube notifications ;)

Re: Rust and WebAssembly in 2019

#66
post #26

Earlier quoted context omitted.

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

This is literally true, but last I checked, Go’s minimum size was about a megabyte, Blazor’s was 300k, and Rust’s is ~100 bytes. That’s what your parent means.

No, parent clearly wrote that Webassembly is limited to Rust and C due to having no Garbage Collection. Which, as I demonstrated, is just wrong.

Re: Rust and WebAssembly in 2019

#67
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 is never going to happen. This is a constant theme on Reddit at r/programming. It is based upon nothing but fear of web technologies (yes, I literally mean fear as a raw and savage emotion) and a lack of understanding what WASM is. It is best to think of WASM as an embeddedable VM for JavaScript rather than opposed to JavaScript. https://webassembly.org/ First of all JS cannot ever be replaced by WASM. This is a…

>there will never be direct DOM access from WebAssembly for security reasons

You should contribute this knowledge: https://github.com/WebAssembly/proposals/issues/16

>developers, [...], tend to be deathly afraid of touching the DOM

I truly have never seen this. In fact, I'd say I often see a rather careless culture of doing DOM manipulation here and there because it solves an immediate problem, albeit by short-circuiting the abstractions that may be in place and are now a bit more fragile.

I am writing JS in the entire stack at the moment and I am mostly happy with it. I don't think that ability will go away but I look forward to the day where I can do the same in Rust or F# or whatever. And it doesn't seem unlikely to me that one day we will see wasm becoming the foundation in browsers, with JS running on top of it like any other language.

Re: Rust and WebAssembly in 2019

#68

Earlier quoted context omitted.

That's only a problem for more traditional websites. For applications 1MB is just not an issue. I imagine there will be some kind of CDN/cache to distribute runtimes. Maybe even a WASM package management system for browsers?

As I said above, this is true for an app, but you wouldn’t want it for every library. That adds up very quick. A CDN may happen; there’s some details that make it tough. We’ll see. npm is already that package manager :)

No need to replace the millions of packages in npm. I predict there will never be a shortage of new javascript frameworks...

No, npm is not THAT package manager. What I am talking about is a way for a user's Browser to download for example a Python 3.7.1 runtime (and similar packages) once, and use it on different sites and applications.

In the simplest form Google or Python.org could serve these files on a CDN. In a more complicated form you could run an application on a range of Python versions, and only download updates when you want and need them.

Re: Rust and WebAssembly in 2019

#69

Earlier quoted context omitted.

We could add support for and not need JS to load it. Once the host bindings are implemented that would be a good fit.

Maybe! There’s not really much demand for such a thing. Web platform people don’t have the disdain for JS that many internet commenters do.

> Web platform people don’t have the disdain for JS that many internet commenters do.

I'm not a web platform person, but I have coded some wasm application as a part of my undergraduate course work, and it is really annoying to use javascript just because rust code cannot be initialized without this BASIC of XXI century.

Outdated unsafe language with outdated unsafe API for DOM access on top of modern language with an ability to design strict, safe and elegant APIs. One need not to be a guru of JS to get access to DOM and to initialize wasm-module, and to write the majority of code in rust, but all this javascript stuff feels like a fifth wheel for a cart: maybe it doesn't hurt much, but it is a dead weight at least.

I mean, I'm not a web platform person, and it is far far away from my day to day work, so maybe I see it all wrong, but I believe that javascript is doomed, like any other fifth wheel. It will last, maybe decade or even more, but it is doomed.

Re: Rust and WebAssembly in 2019

#70
post #65

I decided that Rust is the natural next step for my personal side project stuff, which I want to be more on the browser-based gamedev side of things. The learning curve is enormous - since coming from like Unity and Flash, so much is done for you... I mean, one _can_ write their own shader code and physics and things, but it's not at all required in order to make impressive content. Even in JS, Three.JS and friends t…

Awesome work! I hope you’ll consider involving the gfx-rs project in your learning streak. They are building an all-in-one graphics backend for use in Firefox but also the gamedev ecosystem, e.g. the Amethyst.rs game engine.

https://github.com/gfx-rs/gfx https://github.com/gfx-rs/gfx/issues/1900

Post reply on HN