For C# a single executable over a directory of files. For that and Java, a massive runtime, generally slow cold starts, high initial memory use, reduced relative effectiveness for smaller platforms (RPi and similar).
For JavaScript and Python, slow introp, in addition to the negatives above.
It's also possible to leak memory like a sieve in any language.
- Native interop in Java is surprisingly slow and very clunky (C# interop with C/C++ can be as cheap as direct calls nowadays)
- .NET had been able to produce single-file (and self-contained when needed) executables way before NativeAOT was introduced
- RPi is a fairly large platform compared to e.g. Arduino (for which Rust should be awesome) and can be well-served by NativeAOT (today). I might still use Rust for that one in the long run but using C# wouldn't be an issue both in terms of resource usage and OS since it's just an arm64 musl flavour of Linux usually with 1GB of RAM or more which is a lot for .NET (for context ~256MiB containers with ASP.NET Core image is a popular target for back-ends)
Java also has had possibility to do AOT since around 2000, the difference being that unlike NGEN, it was only available in commercial compilers like Excelsior JET, Aonix, and many others.
PTC, Aicas and microEJ are still around, placing Java in hardware that .NET will never be, even with Meadows.
Panama main goal is to replace JNI performance warts, while Java / ART has had mechanisms to do fast interop (@FastNative and @CriticalNative).
Panama appears to be solving the abysmal UX of JNI but puts the final performance nowhere near close .NET (without even measuring direct P/Invokes which are literal direct C calls if you statically link AOT binary).
Do you have references that say otherwise? (I know you don't, it has JNI level of performance)
p.s.: you have to be insane to use Java today on those listed platforms, which are much better served by C and now Rust. RPi is as small as it gets and on that I'd rather never touch any Java tooling because liking it is literal Stockholm syndrome - it is as low bar as it gets and almost anything else is better.
p.p.s: for anyone's interested, here's the JEP for Panama: https://openjdk.org/jeps/424 do give it a read, then look at C# spans and interop API and ask yourself whether you want to look again at Panama without gouging your eyes out.
In the onterop issue I was referring to JavaScript and Python. As others mentioned, z Java is pretty bad there too.
On the single executable, my understanding is it sad kind of like a self extracting archive that extracted and ran... Meaning slower start times and the need for write access to the file system... Not to mention the framework still needed to be installed. And only more recently was true single executable possible.
What? No. Self-contained means the runtime is packaged in the binary, and then trimmed. Self-extract feature is if you want to package third-party native libraries (think tensorflow) inside your binary instead of separate DLL, it is a separate thing.
You just give the users an exe or unix binary and it runs.
For C# a single executable over a directory of files. For that and Java, a massive runtime, generally slow cold starts, high initial memory use, reduced relative effectiveness for smaller platforms (RPi and similar).
For JavaScript and Python, slow introp, in addition to the negatives above.
It's also possible to leak memory like a sieve in any language.