
Rust to WebAssembly Made Easier - adamnemecek
https://lord.io/blog/2017/wargo/#
======
kibwen
If anyone here has an experience report from attempting to use Rust with
WebAssembly, the Rust team is currently seeking active feedback from users!

[https://internals.rust-lang.org/t/state-of-webassembly-
and-r...](https://internals.rust-lang.org/t/state-of-webassembly-and-
rust/6077)

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

~~~
paulgdp
Hi, I've been using Rust to WebAssembly very recently for a toy project [0]
and posted about it very recently on HN [1].

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](https://buddhabrot.paulg.fr)

[1]
[https://news.ycombinator.com/item?id=15491781](https://news.ycombinator.com/item?id=15491781)

[3] [https://crates.io/crates/ndarray](https://crates.io/crates/ndarray)

[4] [https://github.com/likr/emlapack](https://github.com/likr/emlapack)

[5]
[https://www.npmjs.com/package/weblas](https://www.npmjs.com/package/weblas)

[6] [https://github.com/PaulGrandperrin/rustybrot-
web/blob/master...](https://github.com/PaulGrandperrin/rustybrot-
web/blob/master/src/main.rs)

[7] [http://playground.tensorflow.org](http://playground.tensorflow.org)

~~~
anon333
> but anything that makes it easier to pass and convert/cast object/arguments
> to and from javascript would be welcome.

Perhaps this crate would be of some use to you?

[https://github.com/koute/stdweb](https://github.com/koute/stdweb)

~~~
paulgdp
Thanks, I'll check that out!

------
flavio81
I am not a Rust fan nor user, but I must heartily applaud the sign that the
times are changing -- for that we will finally free ourselves from being
forced to have only one choice (Javascript) for delivering frontend code at
the browser.

Looking forward to many interesting stuff done by leveraging Webassembly to
the max!

~~~
hacker_9
Why would you use Rust over JS for front end work though?

~~~
curun1r
Because a lot of us really hate JavaScript. I see JavaScript as being somewhat
like racism. It used to be really bad and it's gotten a little better. And
those who are happy with the status quo (JS devs) keep saying stuff along the
lines of, "it's better now...I thought we were past this." They're continually
told, "no, from our perspective it's a fundamentally-broken language and we
won't be happy until we can write anything front-end without a single line of
JavaScript." And yet because they're happy with the way things are, they have
problems really hearing that message and understanding just how unacceptable
the current situation is for others.

~~~
bad_user
> _I see JavaScript as being somewhat like racism_

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.

~~~
curun1r
First, Rust is a far superior language to JavaScript, so even if it were a
1-for-1 swap, we'd still be coming out ahead. But you've forgotten a huge
example of a language that fits into your "narrow profile." Swift is also an
LLVM language and people are already writing front-end code in Swift for Apple
platforms. Being able to share front-end code across web and iOS/macOS
platforms will be a huge win. There hasn't been much movement towards
compiling Swift to WebAssembly yet, but there's nothing that should make that
much more difficult than Rust.

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.

------
xuejie
I'm surprised that no one has asked this yet even tho I noticed mentions of
stdweb: any idea how this is different from cargo-
web([https://github.com/koute/cargo-web](https://github.com/koute/cargo-web))?

------
empath75
Seems like wasm would be a better platform for crypto mining in the browser
than js is.

~~~
ManagementBug
Why would anyone mine in browser?

~~~
mrdoops
I don't think mining is the best application of utilizing client side
connections. But surely we can find profitable ways to distribute computation.
I'd be willing to divert the resources of a small sandboxed vm of sorts to
websites if it meant less/no ads. It'd be fascinating to see what people could
come up with if there were a publicly distributed Lambda/Serverless sort of
capability.

------
qbaqbaqba
What does this mean to JavaScript? Google is pushing Dart, Mozilla Rust,
Facebook have their own Reason. Is there any major player supporting
JavaScript?

~~~
steveklabnik
wasm and JavaScript are complimentary, not at odds. Google and Mozilla are
also investing heavily in the future of JavaScript as well as their work on
wasm.

