6 ms·

I think Java is only good for long-running servers. Java doesn’t support C interop. For many desktop and embedded projects this is a showstopper, here’s an exa

I think Java is only good for long-running servers. Java doesn’t support C interop. For many desktop and embedded projects this is a showstopper, here’s an example https://github.com/Const-me/Vrmac/tree/master/VrmacVideo https://github.com/Const-me/Vrmac/tree/master/VrmacVideo That C# code directly consumes V4L2 and ASIO Linux kernel APIs, and calls unmanaged user-mode DLLs like libfdk-aac.so and liba52-0.7.4.so. Native stack and value types in C# reduce load on GC, and the number of complicated tricks required from JIT compiler. This in turn helps with startup performance. This is critical for command-line apps, and very desirable for desktop apps. Another thing missing in Java is intrinsics support, both scalar like popcnt, bitscan, BMI, etc., and SIMD like SSE and AVX.

generichuman 3y ago
Projects Panama & Valhalla seems to solve all your complaints: > Java doesn’t support C interop. For many desktop and embedded projects this is a showstopper, here’s an example https://github.com/Const-me/Vrmac/tree/master/VrmacVideo https://github.com/Const-me/Vrmac/tree/master/VrmacVideo That C# code directly consumes V4L2 and ASIO Linux kernel APIs, and calls unmanaged user-mode DLLs like libfdk-aac.so and liba52-0.7.4.so. Part of Panama: check out the "Foreign Function & Memory API" [0]. The official docs [1] say it is a preview in 21 but it got stabilized in Java 22 (isn't out yet). > Another thing missing in Java is intrinsics support, both scalar like popcnt, bitscan, BMI, etc., and SIMD like SSE and AVX. Also part of Panama: see the "Vector API" JEP [2]. > Native stack and value types in C# reduce load on GC, and the number of complicated tricks required from JIT compiler. This in turn helps with startup performance. This is critical for command-line apps, and very desirable for desktop apps. This is part of Project Valhalla [3], they're adding value types and actual generics, among other things. That said, most of these are not done / not in a stable LTS Java release yet. We'll see how much better it'll be compared to C# (if at all) once they land. [0] https://openjdk.org/jeps/454 https://openjdk.org/jeps/454 [1] https://docs.oracle.com/en/java/javase/21/core/foreign-function-and-memory-api.html https://docs.oracle.com/en/java/javase/21/core/foreign-funct... [2] https://openjdk.org/jeps/460 https://openjdk.org/jeps/460 [3] https://openjdk.org/projects/valhalla/ https://openjdk.org/projects/valhalla/
- Const-me 3y ago
  > Part of Panama Most real-live C APIs are using function pointers and/or complicated data structures. Here’s couple real-life examples defined by Linux kernel developers who made V4L2 API: [0], [1] The first of them contains a union in C version, i.e. different structures are at the same memory addresses. Note C# delivers the level of usability similar to C or C++: we simply define structures, and access these fields. Not sure this is gonna be easy in Java even after all these proposals arrive. For a managed runtime, unmanaged interop is a huge feature which affects all levels of the stack: type system in the language for value types, GC to be able to temporarily pin objects passed to native code (making copies is prohibitively slow for use cases like video processing), code generator to convert managed delegates to C function pointers and vice versa, error handling to automatically convert between exceptions and integer status codes at the API boundary, and more. Gonna be very hard to add into the existing language like Java. > "Vector API" JEP That API is not good. They don’t expose hardware instructions, instead they have invented some platform-agnostic API and implemented graceful degradation. This means the applicability is likely to be limited to pure vertical operations processing FP32 or FP64 numbers. The rest of the SIMD instructions are too different between architectures. A simple example in C++ is [2], see [3] for the context. That example is trivial to port to modern C#, but impossible to port to Java even after the proposed changes. The key part of the implementation is psadbw instruction, which is very specific to SSE2/AVX2 and these vector APIs don’t have an equivalent. Apart from reduction, other problematic operations are shuffles, saturating integer math, and some memory access patterns (gathers in AVX2, transposed loads/stores on NEON). > most of these are not done / not in a stable LTS Java release yet BTW, SIMD intrinsics arrived to C# in 2019 (.NET Core 3.0 released in 2019), and unmanaged interop support is available since the very first 1.0 version. [0] https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Linux/Structures/sStreamDataFormat.cs https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Lin... [1] https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Linux/Structures/sPixelFormatMP.cs https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Lin... [2] https://gist.github.com/Const-me/3ade77faad47f0fbb0538965ae7f8e04 https://gist.github.com/Const-me/3ade77faad47f0fbb0538965ae7... [3] https://news.ycombinator.com/item?id=36618344 https://news.ycombinator.com/item?id=36618344
tkubacki 3y ago
Well maybe you should use C++ or Rust instead of Java or C# in that case? My point is if you are doing business (especially web) apps. Use one of JVM langs insted of C# because ecosystem is much bigger (and it has fresher langs as well like Kotlin - if that's what you care about)
- Const-me 3y ago
  > use C++ or Rust instead of Java or C# in that case? Despite having to spend extra time translating C API headers into C#, the productivity gains of the higher-level memory safe language were enormous. Another example, I have shipped commercial embedded software running on ARM Linux, and based on .NET Core runtime. The major parts of the implementation were written in idiomatic memory-safe C#. > doing business (especially web) apps Well, these business web apps are precisely the long-running servers I have mentioned. Still, the software ecosystem is not limited to that class of problems, and due to different tradeoffs Java is not great for anything else.

generichuman 3y ago

Projects Panama & Valhalla seems to solve all your complaints: > Java doesn’t support C interop. For many desktop and embedded projects this is a showstopper, here’s an example https://github.com/Const-me/Vrmac/tree/master/VrmacVideo https://github.com/Const-me/Vrmac/tree/master/VrmacVideo That C# code directly consumes V4L2 and ASIO Linux kernel APIs, and calls unmanaged user-mode DLLs like libfdk-aac.so and liba52-0.7.4.so. Part of Panama: check out the "Foreign Function & Memory API" [0]. The official docs [1] say it is a preview in 21 but it got stabilized in Java 22 (isn't out yet). > Another thing missing in Java is intrinsics support, both scalar like popcnt, bitscan, BMI, etc., and SIMD like SSE and AVX. Also part of Panama: see the "Vector API" JEP [2]. > Native stack and value types in C# reduce load on GC, and the number of complicated tricks required from JIT compiler. This in turn helps with startup performance. This is critical for command-line apps, and very desirable for desktop apps. This is part of Project Valhalla [3], they're adding value types and actual generics, among other things. That said, most of these are not done / not in a stable LTS Java release yet. We'll see how much better it'll be compared to C# (if at all) once they land. [0] https://openjdk.org/jeps/454 https://openjdk.org/jeps/454 [1] https://docs.oracle.com/en/java/javase/21/core/foreign-function-and-memory-api.html https://docs.oracle.com/en/java/javase/21/core/foreign-funct... [2] https://openjdk.org/jeps/460 https://openjdk.org/jeps/460 [3] https://openjdk.org/projects/valhalla/ https://openjdk.org/projects/valhalla/

Const-me 3y ago
> Part of Panama Most real-live C APIs are using function pointers and/or complicated data structures. Here’s couple real-life examples defined by Linux kernel developers who made V4L2 API: [0], [1] The first of them contains a union in C version, i.e. different structures are at the same memory addresses. Note C# delivers the level of usability similar to C or C++: we simply define structures, and access these fields. Not sure this is gonna be easy in Java even after all these proposals arrive. For a managed runtime, unmanaged interop is a huge feature which affects all levels of the stack: type system in the language for value types, GC to be able to temporarily pin objects passed to native code (making copies is prohibitively slow for use cases like video processing), code generator to convert managed delegates to C function pointers and vice versa, error handling to automatically convert between exceptions and integer status codes at the API boundary, and more. Gonna be very hard to add into the existing language like Java. > "Vector API" JEP That API is not good. They don’t expose hardware instructions, instead they have invented some platform-agnostic API and implemented graceful degradation. This means the applicability is likely to be limited to pure vertical operations processing FP32 or FP64 numbers. The rest of the SIMD instructions are too different between architectures. A simple example in C++ is [2], see [3] for the context. That example is trivial to port to modern C#, but impossible to port to Java even after the proposed changes. The key part of the implementation is psadbw instruction, which is very specific to SSE2/AVX2 and these vector APIs don’t have an equivalent. Apart from reduction, other problematic operations are shuffles, saturating integer math, and some memory access patterns (gathers in AVX2, transposed loads/stores on NEON). > most of these are not done / not in a stable LTS Java release yet BTW, SIMD intrinsics arrived to C# in 2019 (.NET Core 3.0 released in 2019), and unmanaged interop support is available since the very first 1.0 version. [0] https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Linux/Structures/sStreamDataFormat.cs https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Lin... [1] https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Linux/Structures/sPixelFormatMP.cs https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Lin... [2] https://gist.github.com/Const-me/3ade77faad47f0fbb0538965ae7f8e04 https://gist.github.com/Const-me/3ade77faad47f0fbb0538965ae7... [3] https://news.ycombinator.com/item?id=36618344 https://news.ycombinator.com/item?id=36618344

tkubacki 3y ago

Well maybe you should use C++ or Rust instead of Java or C# in that case? My point is if you are doing business (especially web) apps. Use one of JVM langs insted of C# because ecosystem is much bigger (and it has fresher langs as well like Kotlin - if that's what you care about)

Const-me 3y ago
> use C++ or Rust instead of Java or C# in that case? Despite having to spend extra time translating C API headers into C#, the productivity gains of the higher-level memory safe language were enormous. Another example, I have shipped commercial embedded software running on ARM Linux, and based on .NET Core runtime. The major parts of the implementation were written in idiomatic memory-safe C#. > doing business (especially web) apps Well, these business web apps are precisely the long-running servers I have mentioned. Still, the software ecosystem is not limited to that class of problems, and due to different tradeoffs Java is not great for anything else.