I don't think I agree. A debug build of Rust code is often like 40x slower or so than a release build. Those optimizations make a huge difference. Binaryen can only do a fraction of them, so I wouldn't expect AssemblyScript to get close to Rust and C++ (and the benchmarks show that too).
> does AssemblyScript allow the same control over memory layout as C, C++ or Rust?
There's no UB, so in a way AssemblyScript is almost more low level than those, as you have full control over the memory and instructions.
All of that boils down to quality of generated WebAssembly opcodes, nothing prevents an hypothetical AssemblyScript compiler to make use of better optimizations, or being based on LLVM and enjoy the same optimization passes on LLVM IR.
> A debug build of Rust code is often like 40x slower or so than a release build.
Hmm ok, yeah. C++ with heavy stdlib (or generally: template) usage has the same problem (although in my experience it's more like 10..20x slower), but OTH C's debug and release build performance is usually much closer. I guess it's a side effect of generics that they heavily rely on the compiler optimization passes to turn the resulting 'generic mess' into something closer to what a human would write (e.g. remove all the redundant and dead code resulting from 'template resolution').
The main advantage of using Binaryen directly bypassing LLVM is firstly very fast codegen and optimization (Binaryen architecture perfectly utilizes multithreading as opposed to LLVM). In addition, clean and fast debug builds are not clogged with SSA and mSSA noise. That makes debug/release performance not more than 2-4x slower, unlike LLVM where this ratio is 20x-40x as already mentioned. The Binaryen optimizer is improving all the time. It is already better in many places than the same Go's codegen
> does AssemblyScript allow the same control over memory layout as C, C++ or Rust?
There's no UB, so in a way AssemblyScript is almost more low level than those, as you have full control over the memory and instructions.