Compiling Rust to Web Assembly | Hacker News Reader

Compiling Rust to Web Assembly

medium.com

289 pointsgrey-area88 comments

I wasn't a fan of having to compile the dev branch of both emscripten itself, and clang, each time I wanted to try the latest (hence the 'wait 2 hours' in the blog)

I thus asked about providing a Docker image - the person that handles the builds and the SDKs says that nightly builds are on the way: https://github.com/kripken/emscripten/issues/4682#issuecomme...

I read the guide and came here looking to see if there was a docker image. I just don't want to blindly pipe-sh on my host machine (would need to review what rustup is doing first). On top of that, 'wait 2 hours' is not something I want to do when I want to kick the tires on a Hello World.

This is a great example of docker-for-dev. Don't bother setting up the specific versions of compilers and then worry about clean-up afterward.

The guide should be 2 lines: docker pull, then docker run.

Here is an example that using Rust-native library for web development: https://github.com/tcr/rust-todomvc

Also I forked it to use handlebars: https://github.com/sunng87/rust-todomvc

Using asmjs, the compiled js file is about 20MB and can be slow in browser. While wasm32 one is just ~500KB.

Can wasm be chunked up and loaded on demand via AJAX, like JS?

Nice guide.

I did this over the holidays just to see it in action. It was a pain to get the emscripten sdk installed (especially on a slow connection) but it's quite cool to see it in action.

There's also a asm.js target which you can add like this:

$ rustup target add asmjs-unknown-emscripten

I'm not sure about browser support for asm.js but recent versions of node support it.

Every browser supports asm.js, since it's just a subset of standard JS. Some browsers do optimize it, though. https://en.wikipedia.org/wiki/Asm.js#Implementations

Is there a way to debug apps compiled to Web assembly? (Like a gdb.js :D ) I suppose using standard dev tools won't be useful.

https://github.com/WebAssembly/design/blob/master/TextFormat...

That's one area where I would like to see web browsers cooperate a bit. At least Firefox and Chromium. This would give better tools to everyone. I won't bet on it, however.

This is great, I've actually never seen the steps to compiling WASM laid out before.

What all does the Emscripten SDK provide?

An HTML shell that can handle resource loading, plus a bunch of JS methods for providing IO to WebAssembly. In the future it will be possible to do something like https://github.com/brson/mir2wasm to go directly from LLVM to WASM (though IO functionality will need to be supplied separately).

What's the binary size like compared to C/C++?

I've read the overhead of Rust's standard library is about 100kB. Not sure if putting it through the Emscripten toolchain changes that significantly.

In general, https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab...

For this specifically, I made some numbers when it first landed: https://www.reddit.com/r/rust/comments/575pp6/compiling_to_t...

Regardless, this is in a "oh my god it works" state, not a super serious best-we-can-do state. My understanding is that it's larger than it has to be at the moment. We'll get there.

>-rw-r--r-- 1 steve steve 159K Oct 12 20:00 sup.wasm

It's looking pretty good already. Thanks for the reply.

Has anyone heard of python compiled to Web Assembly ?

Python needs all the extra runtime and interpreter cannot just be compiled that easily, except with dropped features.

That reminds me of Google's GWT, which compiled Java to JavaScript and supported a limited subset of the JDK. Maintaining a legacy GWT codebase is not a very pleasant experience, because you are stuck in a Java-like abstraction layer on top of the actual browser features and the DOM.

I guess compiling a language like Rust to WebAssembly solves these issues for a part?

GWT is very different because it directly 'transpiles' Java to a high-level Javascript, you basically get the worst of both worlds ;) asm.js and WebAssembly are much lower level, they are generated from LLVM bitcode, theoretically any language that can be compiled through LLVM can be used with asm.js / WebAssembly (as long as the language runtime libraries are ported to run in a browser environment).

I don't know, but if Web Assembly allows something like dynamic linking, it would enable, for example, Oracle to supply a WASM-JVM via CDN, that JVM based languages could target.

But this would have to be a rather cut-down version of the JVM, I think, so probably not that viable.

As far as I know, if you don't want to add a runtime, you can only compile languages that compile to native code to Web Assembly. C, C++, D, Rust, Nim, etc.

So it's more for low level lanuages to make performance easier on the Web, not for replacing JavaScript in general.

C-python runs on a bytecode interpreter, so theoretically you could port the VM to webassembly, provided you remove features that depend on a native operating system. More bare-bones interpreters like Lua (http://daurnimator.github.io/lua.vm.js/repl.html) and Chibi-scheme (https://chibi-scheme.appspot.com/) which have had their C compilers and vms ported to emscripten can run natively on the web. JIT interpreters like Juajit, Java Hotspot, and pypy, cannot easily run on webassembly or asm.js due to their dependency on native chipsets with self-modifying code support. Also, most of the tooling for wasm and asm.js relies on llvm, so a good amount of work would be required for compiled languages that don't have compilers emmitting llvm bytecode

But don't need D und Nim a runtime for their garbage collection?

Good point. Maybe it's small?

I mean Nim already allows compilation to JavaScript.

Still waiting for an article named 'Compiling Go to Web Assembly' https://imgflip.com/s/meme/Ill-Just-Wait-Here.jpg

Three rust articles on the front page? Not complaining, it definitely seems like the popularity has really jumped up in the last three months.

More Rust discussion and less "future of media/ad supported businesses" discussion works for me.

Not to mention fake news and politics in general.

As far as I know it's because the Rust is filling in the gaps - two of the three articles are about relatively new features. And the next Rust release should close the stable/unstable gap by stabilizing some macro/compiler plugin stuff.

It is a marketing push. Marketing pushes don't have to correlate to massive improvements in the product.

Certainly not a coordinated marketing push. All of the recent Rust posts on HN don't come from any official venues. It's just random community members writing about Rust, and HN upvoting it.

There was a flurry of Rust posts about "why Rust" near the end of the year, which was somewhat "coordinated". In the sense that Steve wrote a post and this triggered a chain reaction where all kinds of folks wrote about related topics. Completely unintentional, just happened. Most of those posts did not make it to HN.

It's just random people discovering Rust due to increased popularity and posting about it (which has a circular effect).

No marketing plan involved, and nobody coordinates these posts.

Quite a few of us made learning rust our new years resolution in recent threads.

and what's the argument here?

Rust and Go are always on the front page.

Also Python, JS frameworks, CLR and JVM languages, C/C++, LLVM, notably obscure languages... It's like there's some kind of theme.

If someone makes a Go compiler in Rust hacker news will have to shut down. Game over, there is nothing left to do in computing.

https://github.com/yberreby/rgo

"A Go compiler, written in Rust."

Clojure-on-Rust

Granted, it would require writing a garbage collector in Rust...

> Granted, it would require writing a garbage collector in Rust...

Why would that be a problem? There are compilers written in C that implement garbage collectors.

Now, writing a garbage collector for Rust, that's another problem entirely

> garbage collector in Rust..

http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rust-ismm...

> Now, writing a garbage collector for Rust,

http://manishearth.github.io/blog/2015/09/01/designing-a-gc-...

(mostly a toy GC, but some folks are using it)

In the future we may have http://manishearth.github.io/blog/2016/08/18/gc-support-in-r...

During my senior year of college (which ended last spring), I worked with two other students on implementing a server-side JavaScript interpreter in Rust. One of us, a grad student (not me!), wrote the garbage collector for it (https://github.com/rustoscript/french-press). We didn't end up finishing the entire language, but we got a sizable chunk of the language features implemented, and more than enough to know that Rust is very well suited to writing programming languages in, including garbage collectors. By far, the most complicated component of getting the garbage collector right was dealing with closures, but that's mostly because JavaScript is a very "unique" language, to put it nicely.

> In the future we may have http://manishearth.github.io/blog/2016/08/18/gc-support-in-r...

I read that back when you first posted it, which is exactly what came to mind when I was writing my comment. At least to my naive understanding, implementing a garbage collector for Rust is several orders of magnitude more difficult than merely implementing one in Rust.

The JS interpreter is pretty cool!

We've had problems with closures before in Servo, I know that pain :)

> implementing a garbage collector for Rust is several orders of magnitude more difficult than merely implementing one in Rust.

Well, I mean it depends on what you're aiming for. Making a safe optional GC in Rust isn't too hard; rust-gc exists and is not very complicated. Making the compiler support arbitrary pluggable GCs is trickier. GC algorithms themselves can get so complicated that the state of the art research probably eclipses whatever has been done with rust-gc and similar "GCs for rust" so far. If you want a GC for Rust that contains a world-class collection algorithm the complexity is additive but the source of most of the complexity isn't the "for Rust" part, it's the "in Rust" part (A GC for rust will also typically be in Rust).

But also "optional" GCs like those that would be useful in Rust haven't been explored much either, so world class algorithms may not even make sense in this case.

It's ... an interesting set of problems, and very hard to make judgement about what is difficult :)

Thanks for elaborating on that! I'm definitely looking forward to seeing what you all do on the GC front for Rust in the future, even if it's a bit beyond my current comprehensions

I hate to ignore the cool technical knowledge needed to implement a GC for JavaScript, but damn, "french-press" is the best possible name for that project, I love it.

There is a lisp dialect on rust https://github.com/murarth/ketos and it doesn't need GC!

Rust compiler written in Go?

TBH it's getting a bit much at this point. The rust advocates here (not sure if they're paid or just fanboys) really need to tone it down. The hyperbole, and the constant "rust solves this unrelated problem, and has no flaws!" is beginning to grate.

I've coded in it a bit and it seems like cool language, they get a lot right and have some new and interesting ideas. But it's not a panacea (or indeed "salvation" as one recent blog post put it) for everything wrong in software. We don't need to all immediately re-write everything we do rust. Not everything new needs to be written in rust. And your re-writes of programs that have already been written in other languages and work well aren't that compelling.

If you like rust, then write some new, interesting and useful software in the language, where what language it's written in isn't the main selling point. For example, I love the look of this http://nickel.rs/.

TL;DR - the corrosive nature of rust advocates on HN is starting to eat away at my patience, and I am tired of having to galvanize against them and their absurd claims.

Like burntsushi I feel you're attacking a straw man here. Or, you're attacking specifically the "salvation" article which was a bit hyperbolic on purpose (in which case you're mostly off topic in this thread)

> the constant "rust solves this unrelated problem, and has no flaws!"

Where do you see that?

> But it's not a panacea for everything wrong in software

Nobody says that. Folks generally focus on the memory safety and thread safety bits. The salvation article did say that Rust can solve all of the problems in software caused by C, which was hyperbolic (I wasn't really fond of that part either), but that's the only instance in a blog post or comment that I can recall this being said recently. There doesn't seem to be a trend as you see.

> We don't need to all immediately re-write everything we do rust. Not everything new needs to be written in rust.

Nobody says that either. If anything, I've seen folks (especially in /r/rust) advocating caution when asked about porting software to Rust.

> If you like rust, then write some new, interesting and useful software in the language, where what language it's written in isn't the main selling point.

There's a lot of this all over the rust community. Redox has reasons for existing other than Rust (https://doc.redox-os.org/book/introduction/why_redox.html). Servo similarly has a wide variety of interesting bits -- some of which have been enabled by Rust but aren't interesting because of Rust. Webrender in particular is something that could have been done without Rust. Servo's layout and style systems are pretty revolutionary, because of the way they work. Ripgrep (http://blog.burntsushi.net/ripgrep/) probably could have been implemented in Go and perhaps still win on some of the benchmarks; it's interesting because of the tricks that burntsushi used. https://github.com/google/xi-editor is also interesting, though incomplete.

There certainly was a phase where many threads about basic software (curl-type stuff, init systems, ...) had comments that felt like endless repeats of "it is 2016, stop writing new C code and just use Rust", which I personally found annoying. I either tuned it out or it has gotten better recently, and I don't think it was a organized effort, just a common pattern.

Yeah, most posts in HN Frontpage with Rust/C/C++ seemd to have a "never Write c(or the baddest: C++!!) in 2k16!1! Its useless because of Rust!"-comment.

Its kinda annoying, but i can ignore them pretty good, so i dont have more like a feel Here. It could be less in the last 1-2 Month(s).

Yes, we had a recent explosion of marketing materials that went a little over the top. That's OK. It happens.

I don't think anyone really believes Rust solves every problem, so I think you're attacking a straw man. There are plenty of trade offs at play. But the problems we believe it does solve makes it exciting for a lot of us (and for perspective users).

Plus it's not really the fault of Rust developers if https://blog.ntpsec.org/2017/01/03/getting-past-c.html gets to the front page; that's not really marketing material for the language.

Hello, I posted this because it looked interesting. I'm not a Rust advocate (I prefer GC-languages personally), the WebAssembly angle and different languages using it as a compilation target was more interesting than Rust specifically.

Right, sorry to hijack the thread, or imply you were one of the people I was talking about.

What are your general thoughts on web assembly? I am really optimistic about it - improving client side performance with a fast IR format will really open up a lot of doors, and make the web a much more viable platform for applications. I do note that many similar attempts have been made in the past though.

> the corrosive nature of rust

Fantastic!

More seriously, I'm not sure who you mean by the paid rust advocates here. There are some core developers who work for Mozilla, but I can't imagine that a Rust-using company or individual would spend salary on an HN advocate rather than paying someone to work on the compiler or ecosystem.

You'd be mistaken. steveklabnik is a hired Rust evangelist who also writes docs.

> Wherever there is discussion about Rust to be found, be it IRC, the RFCs repo, or Reddit/HackerNews, you can be sure to find a comment or two from Steve there, explaining and clarifying the situation.

https://blog.rust-lang.org/2014/12/12/Core-Team.html

To be clear, my job description is "doc writer". I've been posting a ton on HN for _years_, and advocating for Rust before I ever had a job working on it. At the time that post was written, I was a contractor, and it wasn't clear if I was ever going to stay on with Mozilla; historically, I've told everyone this was a short-term gig, though my feelings on that have been changing a bit.

Regardless of that, if you ever hear me saying Rust is a "panacea" or "immediately re-write everything [in Rust]", call me out on it. I don't agree with either of those positions. I want people to accurately understand what's going on, not mislead them.

(I _do_ want to see more people using Rust, because I love it, but not everyone will also love Rust, and that's totally fine.)

Having idled around the same tech watering holes as you have for years, I'd think they'd have to make a significant effort to keep you from talking about it. ;)

I am a pretty active observer of rust community as the language abilities and paradigms excite and suit me. Therefore I do see steveklabnik as well as several others frequent these avenues. In all my time reading Reddit/HN/etc. I've never seen steve or the others "advocate"; they're doing exactly what that description states which is explain and clarify. The tech community brings up rust as a discussion topic and they spend their own time (possibly some of Mozilla's) to make sure that the community understands the organization (not just Mozilla), drive, and tech behind rust.

> steveklabnik is a hired Rust evangelist who also writes docs.

Nobody is paid to evangelize on message boards.

> There are some core developers who work for Mozilla

As a counter, stuff is posted to new every minute, but 90% of it doesn't reach the front page. In order to reach the front, you often have to do make up silly titles such as the ones you mentioned, which cause an emotional response (good or bad, as long as it gets clicks).

HN also has a problem with brigading, which is why you see some utterly random articles make it to the top too. Sadly not much you can do about this, but you could try browsing /r/programming or elsewhere instead.

> HN also has a problem with brigading

More than once as an employee I've been asked to upvote a company post. Obviously I immediately flagged said posts.

> And your re-writes of programs that have already been written in other languages and work well aren't that compelling.

Try ripgrep.

I didn't know how much time I spent waiting for grep until I tried ripgrep!

I enjoy reading about rust.

I don't know the language (yet), but I've been keeping my eye on it for a few years, and I think it's going to be fantastic once it stabilizes and gets improved tooling.

I especially welcome the possibility of using a safe language like rust for web development, instead of writing more dreadful javascript...

Note that Rust is stable now. IDE tooling and stuff isn't there yet (soon?!), and there are other reasons why you may not use Rust, but it is stable.

After 1.0 the Rust releases have been stable, with the stability checked against the entire ecosystem on crates.io. https://blog.rust-lang.org/2014/10/30/Stability.html

> I especially welcome the possibility of using a safe language like rust for web development, instead of writing more dreadful javascript...

There are now a number of typed languages that have solid compile-to-js support. I've done it with OCaml (js_of_ocaml, Bucklescript), F# (Fable), and Elm. For dynamic languages, there's also Clojurescript, which is quite nice.

Reply on news.ycombinator.com