Unless you're asserting that e.g. Python is not interpreted; or you're using the relatively recent native toolchain, C# is interpreted. That's its original state and its widest deployment pattern.
It is true that .NET programs are traditionally distributed as CLR bytecode. This is similar to a .class file or a .pyc file. But the CLR does now, and always has, had a JIT. E.g., the first line or two of https://msdn.microsoft.com/en-us/library/ht8ecch6(v=vs.71).a... , which is for .NET 1.1, which explicitly states that, even at that time, the bytecode is JITed prior to execution.
No and no.
> But the CLR does now, and always has, had a JIT.
And Python has had a JIT[0] for as long as the framework has existed.
[0] https://en.wikipedia.org/wiki/Psyco now replaced by the pypy project
Python is interpreted in what was its most popular form, but may not be now, CPython.
This is using the definition of a JIT as an execution engine which takes in some form of bytecode and, at runtime, emits architecture-specific assembly code to a page, marks that page executable, and changes the IP to that page.
If CPython executes in that manner then I'm mistaken about CPython's execution engine and would also consider CPython to be a JIT.
- JIT and AOT compilation via NGEN up to .NET 4.5.2
- Starting with .NET 4.6, RyuJIT which uses the Visual C++ backend and exposes SIMD support to .NET languages
- When targeting Windows 8 and 8.1, AOT compilation to native code in a format called MDIL. Basically requires dynamic linking on device, everything else will be native code already
- When targeting Window 10 store applications onwards, AOT compilation to static executables
- .NET Compact Framework also always JITs
- .NET Micro Framework is the only one that does interpret MSIL
Also Microsoft .NET JIT compilers, with the exception of the .NET Micro Framework always jit the code, there is no threshold to trigger it like on most JVMs.
If KSP works in C#, you can write a game in Go no problem.