> Swift is statically typed, so it doesn't really compete with JS or Clojure.
This seems to imply that developers make a static vs. dynamic choice separately prior to and separate from evaluating other aspects of languages to choose between them. While some developers may do that all the time, and some may do that some of the time, I don't think its true as a generalization.
Certainly Go is statically-typed, and often portrayed as competing fairly directly with Ruby/Python, which are not.
And .NET code _does_ compile to native code even without NGEN - it just does it 'Just In Time'. It's pretty close to native code just before that step, so the actual native compilation is very fast.
Swift was designed for the iOS platform as a replacement for Apple's dialect of Objective C. This is an unmanaged environment. There's no VM or garbage collection, although both languages support automatic reference counting.
C# was designed for the CLR and has a large standard library that relies on garbage collection. It also has features permitting calls into unmanaged code, but the language was still designed for a VM.
Except there isn't any VM when the code is AOT compiled to native code with NGEN, MDIL in Windows Phone 8, .NET Native, or in iOS.
The presence of garbage collection has nothing to do with being native or not.
Besides a language runtime and VM aren't the same thing.
Actually Swift makes use of Objective-C runtime to achieve interoperability with Objective-C libraries.
Oberon, Oberon-2, Modula-3, Component Pascal, D, Spec#, Dafny are all examples of languages that compile to native code, were used to write operating systems and use garbage collection.
When talking about AOT compilation, we generally tend to mean that the compiler produces a binary consisting of machine code at some unspecified time before the user attempts to run the application.
In the context of that blog post, there are two compilation steps: First emscripten would be used to produce JS. Then Mozilla's JS engine would compile that JS down to machine code at runtime.
They call the latter step with OdinMonkey AOT when they compile the entire thing at runtime, but before starting execution. But the way most people differentiate, this would still be considered JIT - it still depends on executing the compiler each time the application is started.
The point I was trying to get across is that by cross-compiling from C/C++ with Emscripten, static type information can be used to give native performance, that a program written directly in Javascript wouldn't. It's still AOT in that sense - it's not like JIT where only hot bits of code get converted to native to code, and only then when some heuristics have determined what actual types the code ends up dealing with at runtime.
I'm not sure how you claim to be the authority on 'CS speak', but it's a sufficiently blurred line here, for reasons I clearly explained and which you seem unable to understand.
Emscripten/asm.js can use static information to generate Javascript which can be compiled to native code, before the code in question is run, aka Ahead of Time.
Ahead of time compilation is used to describe the process of generating machine code at compilation time, in a form that can be executed directly by a processor without any additional transformation process.
Which clearly is not happening here, as the code is converted into JavaScript and relies on a JavaScript implementation to run. Regardless of the optimization processes used by the JavaScript engine.
Why Swift for multi-platform rather than C#, Clojure, JavaScript, or <insert other language here>?