> If it's still compiling to an IR, and getting JITted at runtime, that seems kind of inefficient in a world where Go exists. It really depends on your use cas

> If it's still compiling to an IR, and getting JITted at runtime, that seems kind of inefficient in a world where Go exists. It really depends on your use case. If you're writing programs with very short run times, for example, then the time spent on spinning up the run-time and JITing the bytecode can amount to a significant portion of the program's execution time. If you're writing a program that's going to run for several seconds or minutes (let alone hours, days or weeks), then the milliseconds spent JITing the bytecode just don't matter. It's also true that, since JIT compilation happens just in time, it doesn't really have the luxury of being able to spend a whole lot of time on optimization. Depending on the kind of problem you're working on, that can make a meaningful difference. Fortran or C would still be my languages of choice for serious number crunching. .NET tends to be used more for I/O-bound or non-performance-critical applications, though, where that doesn't really matter, either.