Hacker News Reader

Comment by steveklabnik | Hacker News Reader

That is incorrect; the smallest rust produced binary is ~100 bytes. Only the code you use is included; if you want an allocator, choosing a smaller one is a good idea, for example.

We are usually significantly smaller than emscripten for the same code.

View on HN

I think Rust and C/C++ are in the same boat here: both can produce tiny wasm binaries of 100 bytes or less. Here's a post about Emscripten generating a 42 byte binary from C:

https://hacks.mozilla.org/2018/01/shrinking-webassembly-and-...

But yeah, as you and others said, while both Rust and C/C++ can do that, there's a lot more going on in the general case. Once you add a malloc/free implementation, or string operations, or anything else, the size increases.

The fundamental issue is that Rust and C/C++ were not designed for this use case. In principle, a new language could do a lot better. If such a language were GC based, it would avoid shipping a malloc/free (once wasm gets GC, that will be "free" for that language). And if such a language had the same string types and a compatible "standard library" with the Web, so that it would just call directly into existing Web APIs, then it would avoid shipping a lot of other code that Rust and C/C++ currently need.

TypeScript, for example, could become such a language. That would probably be the optimal path for creating tiny wasm binaries.

They’ve been working on binary size, and it shows. I didn’t know it went so far already; last I checked it was much bigger. I’ll update that fact in my brain, thank you!

I’m not as convinced as you regarding such a language, for example, once host bindings lands, you’ll be able to call into every API with no overhead, and the bindgen stuff we’re doing will transparently just shrink overnight. But we’ll see! It’s exciting times.

There's an existing project to compile TypeScript to wasm (I haven't used it, not sure about its file size): https://github.com/AssemblyScript/assemblyscript

Yeah, AssemblyScript is great! Huge potential there.

I just programmed a function, which added 2 numbers and compiled it and got a huge binary. But maybe I did something wrong. I will try again. Thanks.

Which target are you using?

I can tell you in a few hours. But it would be easier if you provide me the correct compile options to produce such a small binary for trivial functions. Target was of course the webassembly target.

There's two wasm targets; one with emscripten, one without. It sounds like you were using the one without, which is generally the right one.

the tooling is quite immature at the moment - and tools like Emscripten especially add a lot of bloat. In the future wasm modules will be a lot slimmer. The Rust community are certainly leading the way on that one.

I you did the naive add two number example, you probably also included the whole standard library.

If you really want to go down in size, you either need to compile without the standard library and/or use wasm-gc and wasmopt to remove all the useless code that have been added to your wasm binary.

With this, you can generate wasm binary that weight only a few hundreds octets.

There's a lot of stuff going on. Depending on which rust you used, we didn't do a lot of dead code elimination by default, and the default settings don't optimize for size. The 100 byte thing is the "add two numbers" function, but you have to do a few things.

See here: https://rustwasm.github.io/book/game-of-life/code-size.html

In the future, it will do more of the right things by default, but for now, you have to do some configuration if you want the tiniest possible binary. Early days!

In C for webassembly I can access the provided memory directly, which leads to the following unusual code.

char *m = NULL;

m[1] = 0xFF;

For m[0] the compiler exchanges the code with the abort function :-)

I wonder, if something similar is possible in Rust.

I haven't tried it, but it should do the same thing.

Reply on news.ycombinator.com