3 ms·

This is complicated. I’m no expert with WASM, but I’m fairly familiar with Rust and have toyed around with Rust and WASM. With Rust and WASM you pay an expense

This is complicated. I’m no expert with WASM, but I’m fairly familiar with Rust and have toyed around with Rust and WASM. With Rust and WASM you pay an expense of FFI between the languages. There are tools that minimize this, but there’s still a cost. Transferring data is limited to very primitive data types today, which adds a cost to translation between Rust and JS. I expect this to reduce in cost as WASM gains abilities to access the DOM and such, but it is overhead. This generally means that for many things Rust is not much faster than JS, but it is for very hot loops over CPU bound computations. As to productivity. This debate between languages will never end. JS like Python and other interpreted languages give the impression that tasks are being accomplished, but until all code paths are tested, knowing if it is correct is not obvious. Rust like many other typesafe languages (and it’s definitely on the further end of type safe) allow the compiler to detect errors in usage at compile time, well before testing and production usage. Some of us consider this to be more “productive” as it reduces the overall maintenance of the program after it’s released, but YMMV.

jevgeni 6y ago
Best comment in this thread. To the point and factual.
azakai 6y ago
This is an important point. Languages compiled to wasm have an FFI cost, and we will never fully remove it because it just uses different types than Web APIs do. This isn't a Rust problem or a C problem, it's just how wasm is. Wasm also can't use the JS standard library, and usually ends up shipping some runtime support, like malloc or string handling, which increases download size. Both of those limitations are why wasm won't make sense for the great majority of web dev work. But wasm shines for "engine" type code, like in this post - pure computation, without lots of links to the outside JS/DOM world.

jevgeni 6y ago

Best comment in this thread. To the point and factual.

azakai 6y ago

This is an important point. Languages compiled to wasm have an FFI cost, and we will never fully remove it because it just uses different types than Web APIs do. This isn't a Rust problem or a C problem, it's just how wasm is. Wasm also can't use the JS standard library, and usually ends up shipping some runtime support, like malloc or string handling, which increases download size. Both of those limitations are why wasm won't make sense for the great majority of web dev work. But wasm shines for "engine" type code, like in this post - pure computation, without lots of links to the outside JS/DOM world.