AssemblyScript is one of the best options, because if the only thing you care about is some high level language that outputs WebAssembly, then you are still using Web related tools.
Then D is quite easy to use (LDC alongside betterC mode, runtime is still not fully ported).
Followed by TinyGo, Rust, C#, Nim.
I would leave Emscripten, C and C++, only for porting existing code into the Web, as even with the sandbox memory corruptions of data allocated in the linear memory blocks are susceptible to occur.
> corruptions of data allocated in the linear memory blocks are susceptible to occur
I don't know if I quite understand this. Is this a web-assembly specific thing, or just the standard C / C++ are "unsafe by default" languages which can cause memory corruption etc because e.g. of off by one errors in pointer arithmetic and so on.
WebAssembly doesn't do bounds checking, besides being in bounds of a linear memory segment.
Basically the access is still in bounds of the allocated memory, but not the cells that one actually wanted to access.
From security point of view, while the WebAssembly module is sandboxes, such corruptions can be triggered from the outside, changing the behaviour of the public API.
Then D is quite easy to use (LDC alongside betterC mode, runtime is still not fully ported).
Followed by TinyGo, Rust, C#, Nim.
I would leave Emscripten, C and C++, only for porting existing code into the Web, as even with the sandbox memory corruptions of data allocated in the linear memory blocks are susceptible to occur.