
Get Started with Rust, WebAssembly, and Webpack - milly1993
https://medium.com/@ianjsikes/get-started-with-rust-webassembly-and-webpack-58d28e219635
======
vvanders
Cool to see more people digging into Rust + Emscripten.

Not sure why the guide is using nightly Rust, stable has worked pretty well on
Emscripten for a while. If you need to pass custom linker flags(which
emscripten sometimes requires) you can do it via rustflag directive in
.cargo/config.

We've been using Rust + Emscripten for some cross-platfrom targets(web, win32,
osx, android and linux) and been pleasantly surprised with how
straightforward+stable it's been.

~~~
ianjsikes
Hi, author here. Thanks for the tip, I wasn't aware compiling with Emscripten
would work on stable. That should simplify the process. I'll do some more
research and update the guide.

~~~
vvanders
Yeah, was a great article, kudos for that. To be clear I didn't mean it as a
criticism just wanted to throw it out there so other people knew that it works
on stable.

------
morley
The performance bottlenecks I mostly see as a frontend engineer are those
related to the browser (execution speed, DOM manipulation, and painting). I'm
curious what workloads wasm can improve, since I assume it'll mostly deal with
operations in memory. Maybe physics or graphics calculations in JS game
engines?

~~~
moron4hire
JavaScript as a language also doesn't make a lot of guarantees. Dynamic
languages are great for small projects, but I think we've very clearly seen
from the growing interest in linter tools and gradual type systems like
TypeScript and Flow that there is huge interest in having more static
guarantees. Compiling to WebAssembly has the added benefit of letting you work
in a language that has them already, rather than having to shoehorn them into
a language that wasn't ever designed for it. And if we are going to have a
translation step regardless (ES2016 to ES5), then why not start with something
better than ES2016?

~~~
austincheney
I hear this a lot from people who have little or experience building large
applications in high level languages. If you manage your code properly you can
have strong/static typing in JavaScript. The difference is that nothing yells
at you when you mess that up. Instead the application just runs a little bit
slower.

I have written large parsers and code beautifiers in JavaScript that blow the
shit out of anything I have seen written in other low level languages. There
are a couple of advantages that JavaScript provides for this.

First of all you get immediate execution without a separate build or compile
step. You can see that execution (on really large applications) is a bit
slower the first time due to JIT compilation, but successive executions are
faster because the code is already compiled in memory.

Secondly JavaScript runs almost everywhere. I don't need a special run time or
execution context. I can run JS apps on the command line or browser without
having to push data to a server location and await a response.

Finally, JavaScript is fast now. It executes almost as fast as Java and is
only about 4x-8x slower than C++.

[http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...](http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=node&lang2=gpp)

The biggest limitation I have found with JavaScript is memory management.
Trying to parse a 180mb (or larger) XML file in my JavaScript application can
result in an application crash due to excess memory requirements.

~~~
dragonwriter
> I hear this a lot from people who have little or experience building large
> applications in high level languages. If you manage your code properly you
> can have strong/static typing in JavaScript.

No, you can't. If you manage your code properly, you can have code without the
kind of errors that would be prevented by static typing, but JavaScript does
not have static typing, period. (I mean, you can have it via type annotations
in comments and a separate static analyzer, but that's a type language on top
of JS, not JS proper.)

> The difference is that nothing yells at you when you mess that up.

Which means you don't have static typing; static typing is when the types are
statically verified prior to runtime, and something _does_ yell at you when
they are wrong.

> Instead the application just runs a little bit slower.

Performance problems are the _least_ issue with uncaught type errors. Crashes
and incorrect results are the more common results.

~~~
e12e
Just a small point: machine code/assembler has limited typing too, but that
doesn't mean we say that Haskell isn't strongly typed.

Using any number of languages that compile to javascript can give you just as
strong typing in js as in any language.

(I will grant you that you technically don't "get" strong typing in js, but
rather in the language above it - but for practical purposes, you can have a
language quite like js, with "actual" strong typing).

------
k__
lol, this feels surreal.

This seems like there could be even more stuff automated.

Because Rust is statically typed, a rust-loader could "overload" import() so
it initialises and extracts the exported/non-mangled function signatures and
create the JS equivalents automatically.

    
    
        const {add} = await import("./main.rs");
        add(2,2)

~~~
Matthias247
Sure. But I think a better way would be a separate build tool and step, which
generates the javascript proxy functions. With that way you get code
completions and type checking for the remaining javascript/typescript, if the
loader does everything dynamically you are more likely dynamically typed.

~~~
k__
True, I was just thinking about JavaScript, which is dynamically typed :D

------
bpicolo
"Number" and "i32" are entirely different types. What happens if you have an
impedance mismatch?

~~~
Franciscouzo
IEEE 754 double precision floats have enough precision to represent every 32
bit integer, the problem is when you try to use them to represent 64 bit
integers, you get problems such as this:
[https://github.com/nodejs/node/issues/12115](https://github.com/nodejs/node/issues/12115)

~~~
bpicolo
My question is: what happens when you pass something that's not an integer to
the rust lib code via this?

------
bjt
I was surprised to see the author describe Rust-in-the-browser as "low level".
I always took that term to mean "closer to the metal", and not statically
typed with manual memory management. Rust in this context doesn't seem any
more low level than Javascript, to me.

~~~
lmkg
Web Assembly (and also asm.js) are "closer to the metal" even though they run
in the browser. The execution model is meant to map pretty closely to
assembly, not to JavaScript. The browser is supposed to be doing static
verification for security purposes, but not much in the way of optimization.

------
therealmarv
I'm searching a starter instruction manual for go and WebAssembly. Any
recommendations?

~~~
k__
I don't think Go works with WASM, because it uses a GC.

~~~
anentropic
isn't the GC part of the Go program that gets compiled to WASM though?

The Haskell crowd seemed to think that was how it would work for them:
[https://www.reddit.com/r/haskell/comments/5ydqrc/compiling_t...](https://www.reddit.com/r/haskell/comments/5ydqrc/compiling_to_webassembly/deq0z6m/)

~~~
hackcasual
Not sure that's working. A lot of GC designs need access to program state,
like what's currently on the stack, that's not available in WebAssembly.

------
Animats
I have the horrible feeling that the main applications of WebAssembly will be
hostile code. Ads, malware, spyware, paywalls, and other junk. Look at the
history of Java in the browser, and Flash in the browser. 2% great, 98%
terrible.

Consider WebGL, which is very impressive yet seldom used. There are some very
nice demos, most of them several years old, and some half-finished indy games.
Other than that, not much. Kind of like VRML.

Browsers need a "disable WebAssembly" option. It should require user
interaction to turn it on.

~~~
kristianp
I agree this should be a major concern. How is an adblocker or tracker blocker
going to work when the malicious ad is compiled? It might not be able to
access your machine, but it can drain your battery and deliver malware through
security flaws.

~~~
wuschel
I was wondering about that, too. Perhaps a solution would be a SSL-esque
certificate for a webassembly blob? Just wondering..

