Hacker News Reader

Comment by slackingoff2017 | Hacker News Reader

slackingoff2017

I think everything will eventually settle in the middle where Java and C# currently live.

They have an "intermediate code" that they somewhat compile down to. But this is really a more compact version of the source than a binary though. You can see this easily by running a decompiler. Often times the decompiled IL is almost identical to the source. And before the JIT kicks in the IL is typically interpreted.

You get the best of both worlds. Easy to compile, easy to decompile, platform agnostic, compact code, and fast if it needs to be

View on HN

The Design of Everyday Things is instructive here. You don't design for the middle or the average. You design for the extreme edges. If you have a programming language that can be used both by absolute beginners who just want to learn enough programming to script their excel spreadsheet AND HFT traders who need to ring out every cycle of performance they can on every core they have at their disposal, then the middle will take care of itself.

On .NET's case the IL is never interpreted, it is only a portable executable format.

It is either AOT compiled to native code via NGEN, Mono AOT, MDIL or .NET Native.

Or JITed on file load before actually executing the code.

The only .NET toolchain, from Microsoft, that actually does interpret IL it is .NET Micro Framework.

The idea of using bytecodes as portable execution formats goes back to mainframes, of which IBM AS/400's TIMI is the best known example.

Didn't they use to have a IL interpreter, back in the days? Or was it already a compiler-maskerading-as-an-interpreter?

No, .NET never had an interpreter phase like the JVM.

Which actually can be configured to always JIT as well.

The majority of JVMs have a non-standard flag that allows to configure how the interpreter, JIT or if supported AOT compiler work together.

This is interesting to know, thanks.

It's not optimal for things like embedded, device drivers, high performance computing, etc. So I doubt everything will settle there. There will always be situations where C/Rust/Fortran are better choices.

Reply on news.ycombinator.com