On Friday, 23 June 2017 at 20:13:15 UTC, Paulo Pinto wrote:
ExcelsiorJET is quite easy to figure out, you can download
their open source version.
So in other words, you do not have used these products and only
read their websites, got it.
Some products go the static linking way, others map .jars into
shared libraries.
And how does the tool know which .jars to compile to shared
libraries without running the code first? It can't. Which is why
Excelsior ships with a JIT:
From https://www.excelsiorjet.com/
"First, the AOT compiler turns your jar and class files into a
conventional binary executable. That executable is fully
interoperable with our JVM, which includes a JIT compiler to
handle any classes that were not precompiled."
Nice how you overlook the fact that .NET Native requires static
linking, hence why there are such issues.
AOT compiling to native code with either NGEN or Windows 8 MDIL
compiler doesn't have such issues, because dynamic linking is
used instead.
Again, how can you compile ahead-of-time when you don't know the
dependencies before running the program? You can't which is why
every such tool is at a fight with how these languages work.
In any case, even if native compilation toolchains for Java and
C# aren't perfect, they make it less appealing to try out D if
you don't come up with a solid history to go against them, that
make people actually curious to try out D.
That's just "I looked at the websites, never used these tools in
practice but found them convincing" phrased differently to
pretend you have an argument.
The success of Go strongly indicates people generally don't
connect Java/C# to "native code" or "slim binaries without
dependencies", whom are you kidding here.
