It goes beyond that. Many languages expect that you use types such as size_t or usize for things that are conceptually collection sizes, array offsets, and similar things. In some applications, it's common that the conceptual collection is larger than 2^32 while using relatively little memory. For example, you could have a sparse set of integers or a set of disjoint intervals in a universe of size 2^40. In a 64-bit environment, you can safely mix 64-bit types and idiomatic interfaces using size_t / usize. In a 32-bit environment, most things using those types (including the standard library) become footguns.

I work in bioinformatics. A couple of times a year I check if browsers finally support Memory64 by default. They don't, and I conclude that Wasm is still irrelevant to my work. I no longer remember how long I've been doing that. Cross-platform applications running in a browser would be convenient for many purposes, but the technology is not ready for that.

I would, if the thing stabilized enough.

For example, in a project needed to rely heavily on markdown and needed the exact same markdown renderer on both server and client. That alone made us choose node.js on the server side so that we could use the same markdown module.

Today, I'd probably find a rust / c etc markdown renderer and compile it to wasm. Use it on the server and client as it.

This is a silly example but wasm being a universal runtime would allow interfacing things a lot easier.

Ah also, things like cloudflare workers let you run wasm binaries on their servers. You can write in in any language that can target wasm and you have a universal runtime. Neat.

Because they want to run arbitrary code in a sandboxed environment with well defined interfaces.

You can embed a C/C++ program into arbitrary places using WASM as a runtime, so if you have any C++ program you want to automate, you can "lift and shift" it into WASM and then wrap it in something like TypeScript. This is surprisingly useful. WASM also removes sources of non-determinism, which may enable you to do things like aggressive caching of programs that would normally be slightly non-deterministic (imagine a program that uses a HashMap internally before dumping its output). I use this to run FPGA synthesis and place-and-route tools portably, on all operating systems, with 100% deterministic output: https://yowasp.org/

memory64 support will be very useful, because many non-trivial designs will use a lot more than 4GiB of RAM.

This article give some reasons for Cloudflare workers:

https://shivangsnewsletter.com/p/why-doesnt-cloudflare-use-c...

Sandboxed environment as an alternative to virtual machine or docker container

Think

    uint64_t buffer[1<<32];

and your “pointers” are indexes to that array:

    (void*)(buffer+index)

If some subset of pointers has a guaranteed alignment of 2^N bytes, then the least significant N bits are always zero, and don't need to be stored explicitly (only restored when dereferencing the pointer)

Then why didn't Java do better? Its tagline was write once, run everywhere.

I remember back in the day setting up cross compiling was horrendous though, so I agree, I just don't think it's the only reason. These days all you do is set a flag and rerun "go build", it's stupidly easy, as far as compiling goes.

The other two things that come to mind is that on the web users expect things to look different, so the fact that your cross compiled app looked/behaved like ass on at least one platform unless you basically rewrote the front end to conform to each platforms user interface guidelines (aka write once, rewrite everywhere), meant that websites could look more how the company making the website wanted it to look, and less like how Redmond or Cupertino-bases companies wanted it to look.

The real killer feature though, imo, was upgrading of software. Customer support is a big expense that ends up sinking developer time, and if you got bug reports and you fixed the problem, you'd keep getting bug reports for that issue and the CS team would have to figure out which version the customer is on, buried three menus deep, before getting them to upgrade. The website, however is basically always running the latest version, so no more wasting everyone's time with an old install on a customer's computer. And they showed up in metrics for management to see.