
Rust: Enable WebAssembly backend by default - a_humean
https://www.hellorust.com/news/native-wasm-target.html
======
bluejekyll
This makes me so excited! Great job to Alex and the entire team getting this
done.

I know Rust is not the most perfect language for some. For me, it’s really
exciting that there is finally a high level language which can scale for every
potential use case.

Rust is great for kernels and the embedded space; Excels in the systems space;
Is gaining traction in the native application space; Has great tooling for web
backends; and, now, with WASM, it’s capable of targeting the web (Yes, without
DOM access this is limited, but my understanding is that is coming at some
point in the future).

Are there any other runtime free, memory safe languages that can target all of
those use cases?

~~~
justincormack
I think another contender here would be OCaml/Reason, which has both
JavaScript and WebAsm targeting, is used in systems space (eg Mirage). Its a
bit different in technical choices (functional, GC, for example). Facebook is
using Reason for Messenger for example, on mobile.

~~~
d215
Honest question, Is reason really targeting wasm right now? Do you know a
resource describing this? I cannot find anything about this.

~~~
k__
[https://github.com/sebmarkbage/ocamlrun-
wasm](https://github.com/sebmarkbage/ocamlrun-wasm)

reason == ocaml

~~~
stewbrew
Yes, but a byte code interpreter ported to wasm via emscripten != a compiler
with a WASM backend.

~~~
k__
Isn't the stuff that comes out of the OCaml compiler byte code?

As far as I can tell, OCaml has a GC and WASM (at the moment) doesn't so this
seems like the only viable solution to me.

~~~
colanderman
OCaml also has a native x86 backend, which produces quite efficient code.

------
xstartup
We switched from Go to Rust in production. After the initial ramp-up time,
it's really a lot more productive than Go for us, at least.

~~~
qualitytime
May I ask what "production" is?

~~~
xstartup
Real-time fraud detection as service for adtech companies. We started with
Java but got tired of GC pauses, perhaps due to an inexperienced team but we
were not able to tame it. Then we moved to Go and now we are in Rust.

~~~
make3
that sounds like data science. why aren't you in python?

~~~
kenhwang
He mentioned GC pauses being an issue. Python's GC is significantly less
sophisticated than Java/Go, which were also not satisfactory enough.

------
steveklabnik
I'm so so so excited to see this land! I have a little hello world demo:
[https://gist.github.com/steveklabnik/d86491646b9e3e420f8806a...](https://gist.github.com/steveklabnik/d86491646b9e3e420f8806a286ec8e92)

To give you an idea of file sizes, the above produces a 116 byte wasm file. If
you leave off the no-std stuff it produces a 3059 byte wasm file.

EDIT: I'm actually being told that there was a bug in wasm-gc that's since
been fixed, even with libstd it should be able to eliminate all of it and get
the tiny file now.

~~~
josephg
That’s gorgeous. How much bigger does it grow if you heap allocate? Does it
include 2mb of extra code like in normal desktop builds?

~~~
killercup
This Rust code [1] heap allocates some things (e.g., a string with
`String::from`), and results in this [2] WASM file, which is 65kB, or 25kB
after `gzip -9`.

[1]: [https://github.com/killercup/wasm-
experiments/blob/bf3b30eed...](https://github.com/killercup/wasm-
experiments/blob/bf3b30eed6ca73bfc7809f1d87b6604901d3a0b1/examples/hello.rs)

[2]: [https://github.com/killercup/wasm-
experiments/blob/bf3b30eed...](https://github.com/killercup/wasm-
experiments/blob/bf3b30eed6ca73bfc7809f1d87b6604901d3a0b1/hello-wasm.gc.wasm)

~~~
josephg
Thats much smaller than I expected, especially given how large rust native
binaries usually are. What allocator does that use? Does that 65k include its
own malloc implementation like we needed for asmjs, or does WASM expose a
system malloc library or something?

~~~
steveklabnik
wasm exposes "memory sections", which the module states up-front how much it
wants. It can also generally call a "grow memory" function that makes this
space bigger. That's it, from the direct wasm perspective.

That said, this target uses [https://github.com/alexcrichton/dlmalloc-
rs](https://github.com/alexcrichton/dlmalloc-rs)

------
phkahler
So when will servo become a webapp so we can run it inside firefox?

To clarify, this is sarcasm. What I really want to say is when can we run
firefox inside firefox? But it's not entirely written in Rust. The point of
that question is to illuminate some of the absurdity of web apps. i.e. what
function does the outer browser serve in this scenario and why do we need it?

Edit: All the answers point to the outer browser as providing a sandbox. I
contend that is supposed to be an OS function. I also think that tabs in the
browser came about because OSes didn't provide a decent way to handle multiple
instances of applications. See what's happening here?

~~~
bluejekyll
Your question is related to the technical aspects of the ecosystem, but not to
the way that people use computers in general.

A good rhetorical question in response is, why is the web so much more popular
when using computers than installed applications?

The implication you've made is that there is no benefit to the web, but that
is obviously not true, as web usage far outstrips installed applications
(besides the browser) at this point. Given this, it becomes necessary to have
common tooling to target the different browsers out there.

Getting back to the core of your question, if there was a framework for which
you could target all users on the internet (with a single codebase), it ran
natively on all platforms, was easily run by everyone merely by clicking on an
icon, which then cleans itself up after running... then maybe native apps
would be a good avenue for delivering all applications.

~~~
qznc
What is the advantage of wasm over Java and Flash? I don't really see
technical advantages. There is only the social/legal aspect: wasm is not
controlled by a single corporation.

~~~
Rusky
There is an immense technical advantage: wasm doesn't enforce a high-level
memory model like the JVM's classes or Flash's ActionScript. It allows
straightforward use as a compiler target for low level languages which do not
use a bytecode verifier for safety.

Any attempt to use those languages or their existing ecosystems of code on the
JVM, Flash, or Javascript will be incredibly fragile and convoluted.

~~~
fulafel
The WASM memory is just a Uint8Array in the JS VM. You can use a big byte
array and du manual memory management in JVM too. It's a well known pattern on
the JVM.

~~~
Rusky
That's entirely unhelpful for the call stack, values stored in registers,
loading and storing other sizes, atomics, etc...

Wasm solves that because it's aware of what it's doing. Java et al do not.

------
vincentriemer
Maybe I just can't find it, but the largest blocker for using Rust on the web
for me is a lack of a exposure/binding system (like embind).

I'm not particularly interested in writing entire webapps in Rust but I do see
it being useful for smaller self-contained modules inside a larger JS app. Not
having a robust binding API makes that difficult.

EDIT: But unrelated criticisms aside, congrats on the progress! I'm excited to
see more first class support of WASM from languages other than C/C++.

~~~
themihai
I think the real issue is the lack of DOM access rather than binding to JS.

~~~
ralfn
Isn't the point of the whole architecture that from a security perspective all
IO will always be through JavaScript.

Replicating the attack surface of the browser in JavaScript land in
WebAssembly land goes against the whole design of it.

It's for the community to make nice libraries that expose the browser features
to WebAssembly land in JavaScript. It's also the right place to deal with
cross browser differences.

~~~
themihai
Well the IO is ultimately handled/sandboxed by the browser not by JavaScript
so as far as security is concerned JavaScript and WASM should have the same
access to IO/Web APIs. I think the attack surface you are talking about is
really a implementation detail and browsers could use a common middleware that
both JavaScript and WASM can use.

In a distant future I would see JavaScript actually compiled to WASM(maybe the
browser would pipe it directly into a WASM compiler before to execute it) to
reduce the maintenance costs and perhaps also the attack surface you are
talking about.

The whole point of WASM was to cut off the middle man (i.e. JavaScript) so
that we can reach native-like performance. WASM should be the ultimate
dominator not JavaScript.

>> It's for the community to make nice libraries that expose the browser
features to WebAssembly land in JavaScript. It's also the right place to deal
with cross browser differences.

I believe the community could make nice libraries compiled to WASM that anyone
can use regardless of the programming language. JavaScript would be just
another language(albeit a popular one, at least due legacy reasons).

~~~
ralfn
>I believe the community could make nice libraries compiled to WASM that
anyone can use regardless of the programming language. JavaScript would be
just another language(albeit a popular one, at least due legacy reasons).

I understand and respect the aim -- the browser should be ambivalent about
programming languages.

But this is not intention, because it is quite unfeasable. WebAssembly allows
one to target the web with much more low-level languages, but that also means
that the languages dictate the memory structure of things. In WebAssembly
world there are no 'javascript arrays' or 'object hashmaps'.

Imagine mapping the Javascript DOM API surface (with all its dynamic
datastructures and callbacks) to C++, Haskell and Smalltalk. Three languages
that may compile to WebAssembly, but would have drastically different internal
datastructures. And all of that data marshalling that you would need to do,
would need to happen for every dom feature for every language that compiles to
WebAssembly.

OR! We just implement an API that does nothing more than interop with JS land.
This doesn't change often and it will be easy to support many different
languages quickly.

Think of Javascript as the BASH of the web. In a shell script you would pipe
the output of one written-in-c program to the input of a written-in-rust
program. With HTML+JS you would hookup the heavy part of the application and
plug the IO's exactly how you want them. Its closer to configuration, really,
much like a shell script.

So there needs to be some glue language, and we need to support Javascript and
its DOM operations in a way that is completely backwards compatible, and at
least as fast (read: tighly coupled) as it is now. And we want to limit the
attack surface. There is no other choice than that Javascript will be that
glue language.

But its fitting, because Javascript like BASH is a language whose strongest
competitive advantage is compatibility. Like BASH it will be the glue language
and shell of a platform.

~~~
themihai
The web APIs are described using the Web IDL and I believe that could be
translated to C++ , Haskell and pretty much any language with more or less
effort. In fact I think there are bindings for some languages such Python and
Objective C though they are not open. I see no reason why a WASM interface
could not be exposed (the code itself could be developed in C/C++ and compiled
to WASM)for the web APIs and exposed to the client.

[https://developer.apple.com/library/content/documentation/Co...](https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/DisplayWebContent/Tasks/DOMObjCBindings.html)

[https://www.gnu.org/software/pythonwebkit/](https://www.gnu.org/software/pythonwebkit/)

------
doiwin
I would like to code WebAssembly by hand. Are there any good tools / tutorials
on this?

~~~
lj3
Do you mean something like this?
[https://mbebenita.github.io/WasmExplorer/](https://mbebenita.github.io/WasmExplorer/)

------
substack
And there is already a browserify transform to compile inline rust to
webassembly for browser code:
[https://github.com/browserify/rustify](https://github.com/browserify/rustify)

------
knowThySelfx
Great. I like the way Rust is going on about.

------
stcredzero
What is the Rusty way of handling memory management for a game engine client
deployed on WebAssembly? When a program is running a game loop, there are
certain entities which will stick around across frames, and there are certain
entities which definitely will not. Is there a way to enforce that most of the
implementation of the game reside in pure functions, while making memory
management nearly bulletproof?

~~~
steveklabnik
Nothing about this is specific to WebAssembly; you’d write the same Rust code
as you would for any other target.

~~~
stcredzero
In that case, what's the Rusty way to handle a game loop, in which one wants
to encourage the use of pure functions? I must confess: I'm thinking of using
Rust and a few other languages as a compiler target for a unified Web Client +
Server game engine. Is there a particular way in which Rust could support this
better than other languages compiling to WebAssembly?

~~~
steveklabnik
Rust is not super worried about purity. That said, Rust is also more pure-ish
than not; the large control over mutability and sharing helps. Controlling
allocations is also generally easy, as there's no special things that are
doing allocation behind your back. Arenas/memory pools are well supported too.

> better than other languages compiling to WebAssembly?

The best supported languages for this are C, C++, and Rust. So that's really
the comparison here, IMO.

------
alex_duf
Such a great news!

I'm looking forward DOM integration with wasm, and potentially a way to
compile from scala native to wasm.

------
souenzzo
Once rust is implemented in rust, I can run rustc in browser and get binaries
for windows, for example?

~~~
steveklabnik
Rust is written in Rust, with the exception of LLVM. C++ can be compiled to
wasm too though, so that's not the blocker.

The bigger issue is that rustc uses features that aren't in wasm yet, like
threads and file loading and such. It'll happen eventually, but not just
yet...

------
api
Rust glued to React Native or the latter actually ported to Rust sounds like
Nirvana.

~~~
fleetfox
And webrender as rendering layer for desktop apps to replace electron

------
drhodes
Has anyone given any thought to dynamic linking wasm objects to save
bandwidth?

~~~
steveklabnik
It totally works, it's just not particularly easy to do. wasm modules have
import and export sections; you'd instantiate the std module first, the
instantiate the module that depends on it, pointing its imports at std's
exports. I don't know of any tooling that makes this super easy at the moment
though, you basically have to do it by hand as far as I know.

~~~
kodablah
I don't think you can at runtime from wasm though. Imports are resolved at
load time. Sure there are call indirect that let you dynamically change the
function index but not the import/export. Now if you were willing to reload,
you could use the JS API to create modules at runtime with dynamically
downloaded pieces, but once created, that's it I think.

~~~
steveklabnik
Sure, I'm talking about "instantiate one big module" vs "instantiate several
smaller modules, then finally the last module". Which is a bit different than
what you're talking about; you're right that after you've instantiated, you
can't change imports.

------
idibidiart
How does the performance of WASM compare to JIT'd JS code?

~~~
amelius
This makes me wonder: does WASM allow a JIT (specializer)? I.e., does WASM
allow self-modifying code or code to write code?

If not, then JIT'ed JS could still be faster than WASM.

~~~
steveklabnik
Wasm code is normally JIT-ed by the JS VM. That is, browser implementations
don’t have an entire separate VM for wasm.

------
JepZ
Actually, I don't know why so many people are so excited about webassembly.
Yes, it is faster than JS, but JS itself is not that slow and on the other
hand we loose the open nature of the human readable web.

~~~
Kwastie
Minifiers don't output any readable JavaScript anyway. Yes, it can be
"decompiled" back to something readable, but so can WASM.

~~~
JepZ
Actually, with minified JS you do not have to "decompile" anything. It is just
pressing the pretty print button in your dev-tools and you can use your normal
debugger (just without propper names) to step through the code.

