4 ms·
> So, in general, there is no such thing as a "managed runtime" -- just a collection of features To rephrase my question - why it is not possible to have stati
by zerr 12y ago
> So, in general, there is no such thing as a "managed runtime" -- just a collection of features
To rephrase my question - why it is not possible to have statically linked this collection of features into standalone executable? Like Go. I understand that Go is bare-bones compared to .NET, but Delphi/C++Builder also supports fully standalone executables. As for cross-platform (source) portability - it could use Ahead-Of-Time compilation into native exe.
- pron 12y agoOK, so you're talking about AOT compilation, i.e. doing away with the JIT. Of course it is possible. There are even JVMs that do just that. The question, then, is when is AOT compilation (and static linking) desirable? There are, of course, many situations where it is and many when it isn't. Go is designed mostly for smallish programs (command line programs like Docker or simple services), so static AOT compilation and static linking makes sense. Java, OTOH, is mostly used in large, important, performance-critical server-side services, where the added performance offered by having a JIT is important, and the warmup time isn't, while dynamic linking allows for dynamic code loading/swapping. Just like there are JVMs that do AOT compilation to a native binary, there's nothing stopping .NET from doing the same[1]. There's also nothing stopping a single SDK from providing both options. It usually boils down to a question of what the users of that SDK need. [1]: I would bet that that's exactly where MS is going. Like I said before, writing a good JIT is hard, and OpenJDK's HotSpot is years ahead of the CLR in that respect and only widening the gap with its next-gen JIT, Graal. I think MS would realize that it's easier for them to just do AOT.