Rust to WebAssembly Made Easier
lord.io
lord.io
https://internals.rust-lang.org/t/state-of-webassembly-and-r...
In particular:
1. If you’re using wasm/asmjs and Rust today, how’s it going? Do things generally work well? Are there weird pain points? Is crates.io missing support for key functionality? Is key functionality missing from rustc?
2. If you looked at using wasm/asmjs and Rust historically, but decided not to do so, why not? What are the blockers for enabling your use case with wasm/asmjs and Rust?
3. In general do you have an idea for a use case with wasm/asmjs and Rust on the web? We’re wondering if there’s some sweet uses of wasm/asmjs which really showcase how Rust can shine on the web.
(I'm not the author of that thread, please leave feedback there to keep it all collected in one place.)
So my answers:
1. I'm using both wasm and asm.js (installed using rustup) and it works for me extremely well, no weird bugs, very easy to set up.
However I'm really missing a way to pass arguments to the linker, like "-s BINARYEN_METHOD='asmjs,native-wasm'" or "-s EMCC_DEBUG=1" or "-s DETERMINISTIC=1" or "-s SIMD=1" or "SIDE_MODULE=1"
I think there is already a bug opened for this but I'm not able to find it on Google right now.
From crate.io, I'm missing a N-dimensional array library (BLAS/LAPACK like) that compile to webassembly. There is ndarray[3], but its available BLAS dependencies are using fortran and therefore not compilable to wasm. Maybe thoses projects could help: emlapack[4], weblas[5]
Also, I know it would be difficult to implement and would need some kind of better interaction with emscripten, but anything that makes it easier to pass and convert/cast object/arguments to and from javascript would be welcome. Right now, it requires a lot of boilerplate and unsafe code, mostly with structs [6].
2. I'm using it and considers using it more, I love it, thank a lot to everyone working on it!
3. Right now I'm deep into deep learning and I'm thinking about writting an implementation in Rust (that's why it would be nice to have a BLAS/LAPACK library). It could then be used on the Tensorflow playground[6] to showcase the technology.
[0] https://buddhabrot.paulg.fr
[1] https://news.ycombinator.com/item?id=15491781
[3] https://crates.io/crates/ndarray
[4] https://github.com/likr/emlapack
[5] https://www.npmjs.com/package/weblas
[6] https://github.com/PaulGrandperrin/rustybrot-web/blob/master...
Perhaps this crate would be of some use to you?
#![feature(link_args)]
#[cfg_attr(target_arch="wasm32", link_args = "\
-s TOTAL_MEMORY=268435456 \
-s NO_EXIT_RUNTIME=1 \
")]
extern {}Looking forward to many interesting stuff done by leveraging Webassembly to the max!
Personally I think that’s a good thing, I don’t want front ends to get any more obfuscated than they have gotten.
https://github.com/rust-webplatform/rust-webplatform/issues/...
That said, I think there are better opportunities for wasm than trying to oust JavaScript; that's not really a stated goal of the wasm project.
Really though, the point is that wasm’s goals aren’t somehow eliminating JavaScript, but complimenting it.
That may not be the goal of WASM's creators, but it will certainly be the goal of many of its implementers.
Yes, that's what the wasm guys say, however, what I think is that it will effectively displace Javascript. Not only that, the labor market implications for the current JS full stack developers and front-end developers will be interesting.
Tomorrow, DOM access might actually exist.
1. Java (apple) plugins were not built into the browser; and it was not an internationally agreed standard between browser vendors. You needed to install a big plugin to make it work.
2. Due to the computing capacity of the average PC on those times, startup was slow and it consumed lots of memory.
3. Java applets could only be written in Java.
In comparison:
1. Webassembly is an standard, and its support is built into the browser.
2. Webassembly is very high performance, higher than what users come to accept as good (= Javascript under Google V8)
3. Startup should be quick.
The frontend itself, as in the UI, I'll write in JS, but there are parts that need to be running client-side that aren't really "frontend".
Someone I know built a thing which (for more complicated reasons) ends up speaking HTTPS tunneled over a websocket connection, with a need to terminate TLS within the local JavaScript context. There are a few pure-JS TLS libraries, but it'd be nicer to use an actual TLS library.
Someone else I know literally built a Kerberos client in JS. Again, having the UI in JS seems good but the protocol bits probably shouldn't be in JS. (Also, it is possible that I keep weird company.)
As a maybe more sympathetic example, consider noVNC or Guacamole, which are JavaScript clients for VNC. It would be a lot simpler to just hand an existing VNC implementation a <canvas> and let it do what it's been doing on desktop for years (drawing to a region of memory) than to reimplement VNC in JS.
If you are a Rust developer and need to create some code for the frontend of a web service, this solution allows you to keep your confidence in the language that you are already used to use (Rust in this example) instead of having to worry about the ambiguity of the JavaScript language.
Last comparison I saw gave it about 25% compared to js. And it currently loses in dom manipulation, if you do that a lot it will be slower. It can of course still be worth it but I think people sometimes overestimates the performance gains of wasm.
That's a really dumb thing to say.
Btw, WebAssembly has nothing to do with choice, but with performance, its primary purpose being to let C/C++ to run in the browser. And was preceded by Asm.js.
This is actually very relevant. Going with WebAssembly means you're going low level — e.g. a language author will no longer have the JavaScript runtime to piggyback on, no garbage collector for example. Which might be good news for a language like Haskell, because people now have the opportunity to run the actual GHC runtime and garbage collector in the browser. But you have to port it all and the binary size downloaded by users will have to include everything.
So language implementations like Scala.js or PureScript aren't rushing to WebAssembly yet. In the future anything is possible of course, but currently it's not a useful compilation target for garbage collected languages.
Therefore I don't have good news — if diversity is what you're looking for, then know that WebAssembly was built for C/C++ and Rust and languages not fitting this narrow profile are out.
WASM has been designed to run in the same VMs that run JavaScript.
But the list of LLVM-capable languages is much longer than that. So even if it does force an initial download of a GC, that's still more choice than we have now. And you seem to still be assuming that the JavaScript runtime is a good thing. Lots of us feel otherwise. It's a huge source of bugs and vulnerabilities and the sooner we can ship browsers that no longer rely on it, the better it will be for everyone. WebAssembly will eventually get the equivalent of shared libraries so GCs can be downloaded once from a CDN and cached for future use.
WebAssembly is the first web platform development that promises a future that doesn't rely on JavaScript in any capacity. It's obviously not there yet and initial forays into it will be primarily about performance until crucial web APIs like DOM manipulation are enabled for the platform. But the future of WebAssembly really is about choice and not just performance. Don't confuse the current state with the end state.
When it comes to JS, you already have a gazillion prettier and more enthralling languages to choose from that transpile neatly to JS. Are {{TypeScript/Flow/ReasonML/PureScript/Elm/CoffeeScript/Haxe/Haste/GHCJS/Fay/Fable/WebSharper/Scala.js/GorillaScript/Roy/Idris/etc}} really not enough choice? While wasm is still busy being hatched and birthed, JS has already long become "the web's choice compilation target".
That's not to say that projects compiling to wasm aren't worthwhile of course :D but I observed that the precursor "asm.js" paradigm didn't get widely adopted even though browsers already do optimize-for/precompile it. Unless the whole "EcmaScript + Browser APIs" (dom/xhr/string/array/etcpp) are readily-available from within wasm by default without bridging (ie "the modern web client runtime" exposed fully within wasm -- in a prim-op/pointer fashion I guess), I remain mildly skeptical that it'll take off as "a full JS replacement" rather than remain a pluggable niche component for specialized high-perf computations and such..
As a PL researcher, I can assure you that there is nothing "neat" about transpiling to JS. JS is an awful compilation target.
I'm doing transpilation to Go right now, so often I think "much of this would have been much simpler to get done if I transpiled instead to an anything-goes scripting language". (Reason of course being I want to emit idiomatic human-written-like code, and working with mostly-incomplete type information coming in, still reconstruct types rather than pass-and-return-typeless-boxed-values-around messily.) A lot of this is pretty "messy" right now, but I place all of the blame for that on me (guess I prefer rodeo-ing into it rather than "sitting down and writing a formal paper on it first"), neither the target or source language.
The generated code with “re”constructed control flow is going to be a mess and you can't really help it. Worst-case it'll be a `while(1) { switch(i) {` type of thing.
An omission which, incidentally, is also intentionally present in WebAssembly. There are supposedly good reasons for it, but I still find it really disappointing.
AFAIK, free form records and lack of types do not an easier compilation target make. It's pretty easy to compile an untyped language to a typed language.
> How so?
- There are a ton of implicit casts that are almost certainly not what you want. So, for example, if you're going to use addition in the compiled code, it's a 10-step process [1, section 12.8.3.1], and you should be careful not to trigger the 9 steps that do things other than addition.
- There is, last I heard, no way to determine the size of the stack.
- No integers.
- Say you have a demo page for some language, and someone using the page writes an infinite loop. Don't want the page to crash? Welcome to advanced compilation techniques like CPS transformations and trampolining.
Overall, JS has a ~850 page spec, and any part of the language you target for which you don't fully understand the spec is a potential bug. Instead, you want your target language to be dumb, tiny, and explicit.
[1] http://www.ecma-international.org/publications/files/ECMA-ST...
Disclaimer: I have done research on JS, but I do not study or develop compilers.
Very easy to avoid if you're compiling a statically typed language to JS.
> No integers
Not in the JS specification (outside typed arrays), but every JS JIT works in a way you can actually declare variables as 32 bit signed integers, and made its way into the asm.js specification. They are declared like this:
var a = value|0;
If what worries you is precision and not performance, doubles allow 53 bit integers (not counting sign bit) with full precision.
> Say you have a demo page for some language, and someone using the page writes an infinite loop. Don't want the page to crash? Welcome to advanced compilation techniques like CPS transformations and trampolining.
Or just use a web worker, which you can terminate if you haven't heard back in a while (pun intended).
> and any part of the language you target for which you don't fully understand the spec is a potential bug
It heavily depends on what type of language you do. If your compiler tracks the types and doesn't mix them, edge cases are much, much easier to avoid.
Source: I did make a compiler for my own language that targeted JS.
if value is null / undefined / empty object / empty array, empty string... | 0 wouldn't be no-op it would actually assign 0 to a.
The "|0" trick you mention is not for javascript; it is for asm.js; to be able to declare such a "true integer" variable, your code would need to be in asm.js, not javascript.
Javascript has no integers, only floating point numbers. This is a very strong limitation.
Correctness? The |0 after each operation makes it correct. All bitwise operations in JS operate on signed 32 bit integers.
Speed? All JS JITs have optimizations for integers, and it's the reason asm.js uses that trick, not the other way around.
Precision? If you don't use bitwise operations, you have up to 53 bits of perfect integer precision, plus bit sign. Guaranteed by the standard.
Did you mean the other way around? Certainly it's possible to compile an untyped language to a typed language, but it's nontrivial especially in the presence of duck typing.
What would be your choices?
I wish people would stop using "transpiling". This "to transpile" verb happened in order to inform that a language such as CoffeeScript compiles without information loss to JavaScript -- i.e. they are at the same abstraction level, CoffeeScript being just syntactic sugar.
But when it comes to other languages, like Haskell, Idris, PureScript, Scala, Clojure, those languages are not at the same abstraction level and you lose information by compiling to JS.
And we have had a perfectly adequate term for naming tools that transform one programming language into another – to compile.
You're fine to get upset when people say transpiling isn't compiling.
But getting upset that people use a more specific term than you are, is verging on the overly-pedantic, and isn't going to win you any friends on the other side of the fence.
Check the output of languages like Scala.js and ClojureScript sometimes. The JavaScript those produce can no longer be classified as “source” ;-)
For these languages the generated JS is not higher level or more readable than JVM or CLR bytecode.
By your measure, that wouldn't be considered source code. The original meaning was somewhere along the lines of "not assembled bytecode".
Why the new term then?
Compiling was commonly thought of as including what we now refer to as the assembling step. They wanted to point out they weren't doing that. Editable code, non-hex code, non-binary code, etc. was thought of as source code.
This stuff isn't worth getting upset over. Defining terms to have reasonable conversations has always been difficult.
Here, if you see compiler or transpiler, you understand a transformative process is happening, and so does everyone else.
Accusing someone of misusing a term that can mean different things to people from different backgrounds, or being "wrong", is just going to isolate you from being able to speak reasonably to them.
Our language evolves. A word from nearly thirty years ago is coming into common usage, which means that it's definition will likely change. It might become even become more specific. Most programmers using transcompilers today, don't have thirty years of experience behind them, but they will shape the usage. You can find a middle-ground with them... Or convince them your experience isn't worth listening to.
In addition, there are general purpose languages that compile pretty well to JS:
* OCaml (js_of_ocaml, bucklescript)
* Haskell
* etc.
Many of those languages you listed (for example, TypeScript) run slowly compared to plain Javascript. Transpiling to js is not an easy task and I don't think one can claim it can be done in a "neat" way; see for example the paper that Emscripten authors wrote regarding that topic.
Why should I accept a performance penalty if I write in TypeScript, being so similar to JS? TypeScript is js with typing support. In the outside world (outside of the js ecosystem), if you have a dynamically typed language and you add type annotations to it, performance gets boosted dramatically, 3x to even 10x speed (practical example: Lisp). Not in the case of Typescript. It goes slower than js. Why? Because transpiling to js isn't so nice.
Those langs, compiled to Webassembly, should work much faster, and many will outperform Javascript substantially. Even in simple stuff: Javascript only has floating point numbers. There is a lot of computationally intensive code that will massively outperform the JS equivalent, if implemented using Webassembly using plain integers.
Indeed you shouldn't. TS set out to be "JS with types, that get checked then ditched". Has it morphed into something more? The above shouldn't be slow to generate. And as for code speed, not much code-gen should be happening in the first place once type info is erased from source as "TS turns into JS". I might not be fully up to speed on TS' latest developments however.