Yes, but one can probably trim it down to what is actually used.

Java runtime is only 8MB (JVM) + whatever classes are actually required, other ones can be removed by something like ProGuard or the new linker.

.NET Native is quite similar.

Same applies to OCaml, Haskell, Scala, Go, ....

Wouldn't modules allow you to load the language runtime separately from a CDN, so that it remains cached? Kind of like people do right now with jQuery? It still would be nice if that runtime was slim of course; IIRC mobile browsers especially have small caches.

I think it'll be more like 1..3 MB for something like the .NET mscorlib, but yes, the runtime overhead cost is definitely there. The more "managed" the language is the worse this will be. That's why it makes a lot of sense to use 'bare metal' languages which have a very small, or even completely optional runtime for WebAssembly, and use an 'embedded platform' programming style, that way you can get useful WebAssembly modules down to a few dozen kilobytes.

Just look at Go binaries. They include all the standard library modules that they use. A typical "Hello World" in Golang compiles to around 1-1.5 MB (and that's after you strip debug info).

Correct, shared memory and atomics are likely the first big post-MVP feature: https://github.com/WebAssembly/threads/blob/master/proposals...

Those operations are not available in all hardware architectures anyway, and they surely weren't even common before processors went multi-core.

So GC were implemented within those constraints, which means it is possible to do within the current state, even if it isn't the most optimal one versus the availabilities of such CPU features.