3 ms·

Maybe I'm missing the mark, but isn't server-side wasm basically solving the need for source translation? The semantics of golang and rust are so different tha

Maybe I'm missing the mark, but isn't server-side wasm basically solving the need for source translation? The semantics of golang and rust are so different that any translation runs the risk of producing wildly not-idiomatic code. Of course, you lose out on all the runtime benefits that various platforms might provide (I don't see anyone who is invested in the JVM giving it up for wasm) but why not have rust and golang binaries compiled to a common format and let the communicate directly? Personally, I don't do much polyglot programming these days so I don't really have a dog in the fight, so to speak, but my experience with source-to-source translation is that it tends to be pretty awful short of simple translations that keep the same runtime and underlying data primitives.

imwithstoopid 4y ago
> but isn't server-side wasm basically solving the need for source translation? hypothetically...but it would also move part of your integration testing into the realm of wasm I can't think of why this is better than just translating functionality into the language you are using
- camgunz 4y ago
  > I can't think of why this is better than just translating functionality into the language you are using Because this can be a huge amount of effort.
candiddevmike 4y ago
If you already have to build a wasm target, I don't see why building one for each arch is that much worse, especially if there are probably performance benefits by building platform specific.
mike_hearn 4y ago
> isn't server-side wasm basically solving the need for source translation The hard part about bridging languages isn't solved by WASM, it's about working with complex types across the call boundary. If you want to pass a Python dict to a C++ function that accepts std::map then something will have to do that translation, handle GC concerns, etc. Likewise for function types, object instances, files, strings etc. And then that interop overhead will hurt performance so you may need to optimize that. That's why if you look at Truffle, which is SOTA for this problem, it works in a very different way to WASM. There's no attempt to do a unified bytecode or a COM-like component system. It works with whatever the language's natural representation is and does interop by optimizing and JIT compiling merged partially evaluated ASTs or unrolled bytecode interpreters.

imwithstoopid 4y ago

> but isn't server-side wasm basically solving the need for source translation? hypothetically...but it would also move part of your integration testing into the realm of wasm I can't think of why this is better than just translating functionality into the language you are using

camgunz 4y ago
> I can't think of why this is better than just translating functionality into the language you are using Because this can be a huge amount of effort.

candiddevmike 4y ago

If you already have to build a wasm target, I don't see why building one for each arch is that much worse, especially if there are probably performance benefits by building platform specific.

mike_hearn 4y ago

> isn't server-side wasm basically solving the need for source translation The hard part about bridging languages isn't solved by WASM, it's about working with complex types across the call boundary. If you want to pass a Python dict to a C++ function that accepts std::map then something will have to do that translation, handle GC concerns, etc. Likewise for function types, object instances, files, strings etc. And then that interop overhead will hurt performance so you may need to optimize that. That's why if you look at Truffle, which is SOTA for this problem, it works in a very different way to WASM. There's no attempt to do a unified bytecode or a COM-like component system. It works with whatever the language's natural representation is and does interop by optimizing and JIT compiling merged partially evaluated ASTs or unrolled bytecode interpreters.