[flohofwoe]

Rust is currently developing so fast that this bullet point in the manifesto is nearly obsolete. C/C++ currently still has the edge for multiplatform-support (emscripten, PNaCl, iOS, Android(?), game consoles), but that's about the only remaining point. With Rust it is also easy to integrate existing C libraries (e.g. middleware libraries for game development), which is usually the main problem when choosing a language other them C/C++ for game development.

[mrec]

Yeah, I'm not sure what the current outlook is for Rust+Emscripten. I'd hoped that the recent runtime removal might put that back on the table, but haven't seen any explicit confirmation of that.

Rust programs also seem to produce big binaries, even with LTO, which would be another strike against it for web delivery.

[kibwen]

Rust's big binaries (these days, about 500kb for hello world) are due to the combination of two factors: 1) it statically-links by default (if you opt for dynamic linking, you get the typical C-esque 10kb binaries) and 2) it ships jemalloc as a custom allocator rather than relying on the system allocator. Considering that jemalloc would be unnecessary for any program targeting a web-based platform, you'd be able to strip down the compiled size considerably.

[mrec]

Is jemalloc's footprint really in the hundreds of kilobytes?

[kibwen]

As source I cite this PR that just landed today:

https://github.com/rust-lang/rust/pull/20218

"It's quite possible that small programs don't use all of jemalloc, and building with -ffunction-sections and -fdata-sections allows the linker (via --gc-sections) to strip out all unused code at link time. This decreases the size of a "hello world" executable for me from 716K to 482K with no measurable impact on link time. After this patch jemalloc is still the largest portion of our hello world executables, but this helps cut down on the size at least somewhat!"

[arena_lover]

on Rust+Emscripten:

http://www.reddit.com/r/rust_gamedev/comments/2n0x08/emscrip...