> Quick search indicates that it comes at an explicit huge performance tradeoff however.
That's definitely true, but it should be possible to reimplement JNA on top of the new FFM APIs for convenient imports and high performance at the same time.
> Of course the numbers can be presented in a much more .NET-favored way by including the allocations that Java has to do in the absence of structs and other C primitives.
Hopefully Project Valhalla will allow fixing that, the current workarounds aren't pretty.
I fully agree though that .NET is far superior in terms of native interop.
> As the previous conversation indicates, you are not familiar with C# and its toolchain,
I've been using .NET for far over a decade now. I even was at one of the hackathons for Windows Phone developers back in the day.
Sure, I haven't kept up with all the changes in the last 2-3 years because I've been so busy with work (which is Kotlin & Typescript).
That said, it doesn't seem like most of these changes have made it that far into real world projects either. Most of the .NET projects I see in the real world are years behind, a handful even still targeting .NET Framework.
> were wrong on previous points as demonstrated.
So far all we've got is a back and forth argument over the same few points, you haven't actually shown any of my points to be "wrong".
> I've been using .NET for far over a decade now. I even was at one of the hackathons for Windows Phone developers back in the day.
This conversation comes up from time to time. It is sometimes difficult to talk to developers who have a perception of .NET that predates .NET Core 3.1 or so and newer. Windows Phone and its tooling is older. I am sad UWP has died, the ecosystem needs something better than what we have today, and the way Apple does portability with MacCatalyst is absolutely pathetic. In a better timeline there exists open and multi-platform UWP-like abstraction adopted by everything. But these were other times and I digress.
The package distribution did not change significantly besides small things like not having to write .nuspec by hand in most situations. Nuget was already good and far ahead of the industry at the time it was introduced.
The main change was the switch to SDK-style projects files. Kind of like Cargo.toml but XML.
Adding a file to a nuget package (or anything else you build) is just adding a <Content ... /> item to an <ItemGroup>.
As you can see, it is possible to make definitions conditional and use arbitrary information provided by the build system. It is very powerful. I don't know what made you think that I assume anything about .jar files.
Together with <PublishAot> property, invoking 'dotnet publish -o .' calls into cargo to build a static library from Rust, then compiles C# project, then compiles the produced .NET assemblies to native object files with ILC (IL AOT Compiler), and then calls system linker to statically link together .NET object files and a Rust object file into a final native binary. The calls across interop, as annotated, become direct C ABI calls + GC poll (a boolean check, multiple checks may be merged so less than a branch per call).
This produces just a single executable that you can ship to users. If you open it with Ghidra, it will look like weird C++. This is a new feature (.NET 7+) but even without NativeAOT, it was already possible to trim and bundle CIL assemblies into a single executable together with JIT and GC. As far as I'm aware, the closest thing that Java has is Graal Native Image, which is even more limited than NativeAOT at the present moment (IL linker has improved a lot and needs much less annotations, most of which can be added as attributes in code and the analyzer will guide you so you don't need trial and error). And the project that allows to embed bytecode in the .NET trimmed single-file style in Java is still very far from completion (if I understood it right).
I think https://two-wrongs.com/dotnet-on-linux-update is more or less representative of unbiased conclusions one makes when judging .NET by its merits today. You can always say "it used to be bad". Sure. It does not mean it still is, and the argument is irrelevant for greenfield projects, which is what I advocate C# is the better choice for anyway.
> I fully agree though that .NET is far superior in terms of native interop.
This is not limited to native interop. At its design inception, C# was supposed to replace C++ components at MS. Then, in C# 2, a focus group including Don Syme if I'm not mistaken pushed for generics and other features. Someone posted a history bit here on HN.
This and influence from the projects like Midori (spans, struct improvements), and subsequent evolution (including the existence of Mono) and especially after it stopped being .NET Framework and became .NET resulted in a language that has much wider scope of application than most other GC-based languages, including Java, particularly around low-level tasks (which is also why it's popular in the gaming industry).
Unfortunately, the perception of "another Java" hurts the ecosystem and discourse significantly, as the language and the platform are very unlike this claim.
That's definitely true, but it should be possible to reimplement JNA on top of the new FFM APIs for convenient imports and high performance at the same time.
> Of course the numbers can be presented in a much more .NET-favored way by including the allocations that Java has to do in the absence of structs and other C primitives.
Hopefully Project Valhalla will allow fixing that, the current workarounds aren't pretty.
I fully agree though that .NET is far superior in terms of native interop.
> As the previous conversation indicates, you are not familiar with C# and its toolchain,
I've been using .NET for far over a decade now. I even was at one of the hackathons for Windows Phone developers back in the day.
Sure, I haven't kept up with all the changes in the last 2-3 years because I've been so busy with work (which is Kotlin & Typescript).
That said, it doesn't seem like most of these changes have made it that far into real world projects either. Most of the .NET projects I see in the real world are years behind, a handful even still targeting .NET Framework.
> were wrong on previous points as demonstrated.
So far all we've got is a back and forth argument over the same few points, you haven't actually shown any of my points to be "wrong".