What bothers me about asm.js and Emscripten is that, if used on a large scale, they'll perpetuate the C memory model, that is, a single flat heap of arbitrary s

What bothers me about asm.js and Emscripten is that, if used on a large scale, they'll perpetuate the C memory model, that is, a single flat heap of arbitrary size in which things are referenced via fixed pointers. Perhaps this memory model is necessary for small pieces of high-performance code, but I wouldn't want us to keep using it as the primary memory model for new applications, especially when at least some of the current JS engines have advanced copying/compacting garbage collectors. I would love to have a memory-safe language that compiles to efficient JavaScript with no intractable semantic or runtime mismatches between the JS and the source language or its libraries (e.g. no preemptive threads with shared memory) and takes full advantage of the JS engine's garbage collection, but can also be compiled ahead-of-time to fairly efficient native code for environments where JIT compilation isn't an option (e.g. iOS apps). I suspect that a language like this would need static typing. To gain traction, such a language would need to stick to fairly mainstream concepts (e.g. not purely functional). Perhaps this language could be a subset of JS itself. The trouble with Java and C# is that their standard libraries and most third-party libraries assume multiple threads and blocking APIs; perhaps the compiler to JS could transform the code into continuation passing style.