NEneonsunset·Aug 29, 2024
> The primary issue I've got with the .NET ecosystem is actually closely related to that. Because it's so easy to import native libraries, often there's no .NET version of a library and everyone uses the native one instead. But if I actually want to build the native one I've got to work with ancient C++ build systems and all the arcane trouble they bring with them.
What is the reason to continue making statements like this one? Surely we could discuss this without trying making accusations out of thin air? As the previous conversation indicates, you are not familiar with C# and its toolchain, and were wrong on previous points as demonstrated. It's nice to have back and forth banter on HN, I get to learn about all kinds of cool things! But this happens through looking into the details, verifying if prior assumptions are still relevant, rea
Read the rest
ding documentation and actually trying out and dissecting the tools being discussed to understand how they work - Golang, Elixir, Swift, Clojure, etc.
> You seem to have misunderstood. The fun part of the maven ecosystem is that a dependency doesn't have to be a jar, it can also be an XML that resolves to one or multiple dependencies depending on the environment.
Same as above.
> JNA
I was not aware of it, thanks. It looks like the closest (even if a bit more involved) alternative to .NET's P/Invoke. Quick search indicates that it comes at an explicit huge performance tradeoff however.
From https://github.com/zakgof/java-native-benchmark?tab=readme-o...
"Now let's look into performance of the native call only, stripping out the struct allocation and field access:"
Native call only (average time, smaller is better)
JmhCallOnly.jna_direct 1373.435 ± 70.343 ns/op
JmhCallOnly.jna 1346.036 ± 72.239 ns/op
JmhCallOnly.bridj 383.992 ± 50.000 ns/op
JmhCallOnly.jnr 298.334 ± 48.785 ns/op
JmhCallOnly.jni_javacpp 56.605 ± 8.087 ns/op
JmhCallOnly.foreign 49.717 ± 6.667 ns/op
This uses Win32 API. I will post numbers in a bit. .NET interop overhead in this scenario usually comes at 0.3-2ns (i.e. single CPU cycle which it takes to retire call and branch instructions) depending on the presence or absence of GC frame transition, which library loader was chosen and dynamic vs static linking (albeit with JIT and dynamic linking the static address can be baked into codegen once the code reaches Tier 1 compilation). 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.