[pmontra]

On the other side, not being able to run on iOS didn't kill any server side language (think Java.) And Java client side (Android) is very different from Java server side, down to the sets of developers.

Currently WASM is both a client side and server side runtime. It's not clear where it will be in 5 or 10 years. I don't see a compelling server side story. Why WASM and not C#, Java, Node, Python, Rails (I intentionally don't write Ruby) or whatever any of us is using now with its standard runtime?

[dragonwriter]

> Why WASM and not C#, Java, Node, Python, Rails (I intentionally don't write Ruby) or whatever any of us is using now with its standard runtime?

I don't understand why you use a framework instead of a language there, but it seems to be in the same category of mistake as asking “why <compilation target> and not <thing that can be compiled to that target>”. They aren't mutually exclusive alternatives.

[no_wizard]

In a phase: code sharing.

Say you are a C# developer and there is a C / C++ / Rust thing you want to use as a dependency.

Well, WASM is your interop layer. Same with Node.js, Deno, Go etc. You can start to share alot more code with a solid interop layer that WASM presents.

[pjmlp]

Just like CLR has been doing for 20 years.

IBM and Unisys almost since the 1960's, depending on which model we are talking about.

[int_19h]

wasm does not have a solid interop layer, especially compared to past attempts such as CLR. What you get at the moment is more or less the C FFI, but more awkward to use because of the sandbox.

[nikki93]

Personally I'm not super familiar with its benefits if any on the server and would actually not use it on the server myself and just build binaries directly, probably using Go. But I've seen some references to Wasm on the serverside for something similar to containerization or loading plugins. It does seem less obvious to me than the client side.

What makes you say Wasm is a server side runtime / imply that it's meant to be one?

[0x20cowboy]

With go as an example, you know the saying “cgo isn’t go”? Well, you could use C, C++, Rust or anything else that compiles to wasm from any other language.

There have been a few people who say if wasm (WASI on the server) existed already, Docker wouldn’t need to exist. Docker runs a whole OS just to run your binary - imagine the benefits of Docker but just running your binary.

It’s all early days so I am slightly waving my hands, but a lot of this works now. Check out _wasmtime_.

[nikki93]

For the client I use a simple go -> c++ compiler I wrote and compile to wasm from that actually, on my side projects. It had zero overhead interfacing to / calls to C/C++ (including generics<->templates) since it's just generating that. Example web game made with that: https://github.com/nikki93/raylib-5k

I think I've seen wasmtime before. If I needed to interface to any C/C++ things on the server I would probably just write in C/C++ (or Gx) yeah.