4 ms·

> {my favourite package} Well, that's where the problem lies, isn't it? The ecosystem for .NET is extremely limited compared to what's available for the JVM A

> {my favourite package} Well, that's where the problem lies, isn't it? The ecosystem for .NET is extremely limited compared to what's available for the JVM And the way JVM packages are distributed, with native libraries, BOMs and platforms allows more versatility than any other platform. The build system may be better in dotnet, but that only really matters for the first 10 minutes. Afterwards, the other tradeoffs become much more important.

neonsunset 2y ago
I don't think "JVM is more popular" argument does justice to Java (and Kotlin) strengths. With this reasoning, you could also say "C++ is more popular for systems programming" but it doesn't stop developers from switching to Rust, Zig or even C# as a wider scope and easier to use language that has gotten good at it. Nonetheless, you could make this argument for select Apache products, but that's Apache for you. It does not hold true for the larger ecosystem and, at the end of the day, quantity is not quality, otherwise we would've all been swept by Node.js :) Same applies to "packages that bundle native libraries". First, they are always maintenance-heavy to manage with ever growing matrix of platforms and architectures. Just x86 alone is problem enough as all kinds of codecs perform wildly different depending if AVX2 or 512 is available vs SSE4.2 or even SSE2 without EVEX. Now add ARM64 with and without SVE2 to the mix. Multiply this by 2 or 3 (if you care about macOS or FreeBSD). Multiply linux targets again by musl and glibc. You get the idea. This a worst-case scenario but it's something Java is not going to help you with and will only make your life more difficult due to the reason below. There is also an exercise in writing JNI bindings. Or maybe using Java FFM now which still requires you to go through separate tooling, build stage, deal with off-heap memory management API and still does not change the performance profile significantly. There's a reason it is recommended to avoid native dependencies in Java and port them instead (even with performance sacrifices).* Green Threads will only exacerbate this problem. Meanwhile using System.Runtime.InteropServices; [DllImport("libc", EntryPoint = "putchar")] static extern int PutChar(int c); var text = "Hello, World!\n"; foreach (var c in text) PutChar(c); since C# 2 or maybe 1? No setup required. You can echo this snippet into Program.cs and it will work as is. (I'm not sure if binding process on the ole Mono was any different? In any case, the above is a thing on Linux since 8 years ago at least) Like with other false claims, the "better native packaging" one is easily disprovable. Just look at the list of supported platforms here: https://github.com/sandrohanea/whisper.net?tab=readme-ov-file#supported-platforms https://github.com/sandrohanea/whisper.net?tab=readme-ov-fil... It even supports CoreML on iOS and macOS. * Now applies to C# too but for completely different reason - you can usually replace data crunching C++ code with portable pure C# implementation that retains 95% of original performance while reducing LOC count and complexity. Huge maintenance burden reduction and "it just works" without having to ship extra binaries or require users to pull extra dependencies.
- kuschku 2y ago
  > There is also an exercise in writing JNI bindings. Or maybe using Java FFM now which still requires you to go through separate tooling, build stage, deal with off-heap memory management API and still does not change the performance profile significantly. There's a reason it is recommended to avoid native dependencies in Java and port them instead (even with performance sacrifices).* Green Threads will only exacerbate this problem. I'm not sure if you've used JNA before? That's been the state of the art for many years: https://github.com/java-native-access/jna https://github.com/java-native-access/jna public interface MSVCRT extends Library { public static MSVCRT Instance = (MSVCRT) Native.load("msvcrt", MSVCRT.class); void printf(String format, Object... args); } public class HelloWorld { public static void main(String[] args) { MSVCRT.Instance.printf("Hello, World\n"); for (int i=0;i < args.length;i++) { MSVCRT.Instance.printf("Argument %d: %s\n", i, args[i]); } } } > "C++ is more popular for systems programming" Sure, and it's got many great libraries – but actually using those is horrible. You're absolutely right about Rust though. crates.io and cargo are amazing tools with a great ecosystem. 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. > Same applies to "packages that bundle native libraries". 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.
  - neonsunset 2y ago
    > 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, reading 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-ov-file#results 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.

neonsunset 2y ago

I don't think "JVM is more popular" argument does justice to Java (and Kotlin) strengths. With this reasoning, you could also say "C++ is more popular for systems programming" but it doesn't stop developers from switching to Rust, Zig or even C# as a wider scope and easier to use language that has gotten good at it. Nonetheless, you could make this argument for select Apache products, but that's Apache for you. It does not hold true for the larger ecosystem and, at the end of the day, quantity is not quality, otherwise we would've all been swept by Node.js :) Same applies to "packages that bundle native libraries". First, they are always maintenance-heavy to manage with ever growing matrix of platforms and architectures. Just x86 alone is problem enough as all kinds of codecs perform wildly different depending if AVX2 or 512 is available vs SSE4.2 or even SSE2 without EVEX. Now add ARM64 with and without SVE2 to the mix. Multiply this by 2 or 3 (if you care about macOS or FreeBSD). Multiply linux targets again by musl and glibc. You get the idea. This a worst-case scenario but it's something Java is not going to help you with and will only make your life more difficult due to the reason below. There is also an exercise in writing JNI bindings. Or maybe using Java FFM now which still requires you to go through separate tooling, build stage, deal with off-heap memory management API and still does not change the performance profile significantly. There's a reason it is recommended to avoid native dependencies in Java and port them instead (even with performance sacrifices).* Green Threads will only exacerbate this problem. Meanwhile using System.Runtime.InteropServices; [DllImport("libc", EntryPoint = "putchar")] static extern int PutChar(int c); var text = "Hello, World!\n"; foreach (var c in text) PutChar(c); since C# 2 or maybe 1? No setup required. You can echo this snippet into Program.cs and it will work as is. (I'm not sure if binding process on the ole Mono was any different? In any case, the above is a thing on Linux since 8 years ago at least) Like with other false claims, the "better native packaging" one is easily disprovable. Just look at the list of supported platforms here: https://github.com/sandrohanea/whisper.net?tab=readme-ov-file#supported-platforms https://github.com/sandrohanea/whisper.net?tab=readme-ov-fil... It even supports CoreML on iOS and macOS. * Now applies to C# too but for completely different reason - you can usually replace data crunching C++ code with portable pure C# implementation that retains 95% of original performance while reducing LOC count and complexity. Huge maintenance burden reduction and "it just works" without having to ship extra binaries or require users to pull extra dependencies.

kuschku 2y ago
> There is also an exercise in writing JNI bindings. Or maybe using Java FFM now which still requires you to go through separate tooling, build stage, deal with off-heap memory management API and still does not change the performance profile significantly. There's a reason it is recommended to avoid native dependencies in Java and port them instead (even with performance sacrifices).* Green Threads will only exacerbate this problem. I'm not sure if you've used JNA before? That's been the state of the art for many years: https://github.com/java-native-access/jna https://github.com/java-native-access/jna public interface MSVCRT extends Library { public static MSVCRT Instance = (MSVCRT) Native.load("msvcrt", MSVCRT.class); void printf(String format, Object... args); } public class HelloWorld { public static void main(String[] args) { MSVCRT.Instance.printf("Hello, World\n"); for (int i=0;i < args.length;i++) { MSVCRT.Instance.printf("Argument %d: %s\n", i, args[i]); } } } > "C++ is more popular for systems programming" Sure, and it's got many great libraries – but actually using those is horrible. You're absolutely right about Rust though. crates.io and cargo are amazing tools with a great ecosystem. 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. > Same applies to "packages that bundle native libraries". 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.
- neonsunset 2y ago
  > 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, reading 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-ov-file#results 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.