> 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

> 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.