4 ms·

The JVM does not have ‘all the advantages of a fully native language’: fully native code does not need a runtime, or a garbage collector.

malfist 2y ago
Some would say a garbage collector is an advantage a fully native language doesn't have.
- jmartin2683 2y ago
  ??? There are lots of examples of this.
- Jtsummers 2y ago
  D, Common Lisp, Go. All natively compiled (or can be in the CL case) with garbage collection.
- pfdietz 2y ago
  You can bolt a conservative GC onto things compiled by an ordinary C compiler. https://en.wikipedia.org/wiki/Boehm_garbage_collector https://en.wikipedia.org/wiki/Boehm_garbage_collector
caspper69 2y ago
I know HN is not the place for this (because Microsoft), but I really like C#. The ecosystem has been MIT since 2016, and the last few releases have been solidifying the AOT proposition. It just has so many features that allow it to compete with C/C++ on the low level, but it also provides exceptional high level niceties (which admittedly can be slow, some LINQ for example). I know it's not fashionable, especially in a Linux-centric world, but I have used it extensively for many years (on essentially every platform), and it's lightweight (in most instances) and has the features and tooling to make development less stressful. Every time I use Java, it just feels overwhelming and slow.
- jeroenhd 2y ago
  I like C# too, but both languages seem to perform pretty similarly in my experience. The biggest difference seems to come from third party libraries being more optimized in one framework than the other. Once Project Loom receives some more love (I believe that's scheduled for the next LTS, Java 25) I'll be very interested to see how Java's green threads will compare to C#'s async/await. I think Java's model may help programmers write more optimal code easier, but only if they can pull off their scheduling improvements. C# does have massive advantages when calling native code, though. Java FFI is always just kind of a pain and C# FFI is pretty much trivial.
Jtsummers 2y ago
Garbage collection is orthogonal to "native", by which I take you to mean compiled to native machine code as opposed to something like Java's bytecode compilation or an interpreted language. Go, D, Common Lisp (implementation dependent), and others offer GC and native compilation. If you count automatic reference counting like Objective-C's ARC, you can add it and Swift to the list of natively compiled languages with GC.
- superjan 2y ago
  I don’t disagree, but I was responding to a claim that the JVM has _all_ the advantages of fully native languages. Fully native allows you to choose to have no runtime, or a garbage collector, and in some environments (realtime, OS kernel, AAA games) that is overwhelmingly the preferred option.
  - deleted 2y ago
    [deleted]
  - blibble 2y ago
    in Java you can turn off the GC completely and you can also compile to native code
    - shizzy0 2y ago
      You can in theory turn off gc but in practice no one does this because nearly everything is written with the assumption that allocations will be cleaned up by the gc. The compiler has no switches to help you run in a non-gc’d state. At best you can control when you run the gc.
      - blibble 2y ago
        > nearly everything is written with the assumption that allocations will be cleaned up by the gc zero garbage Java it is relatively common in algorithmic trading > but in practice no one does this that's funny, I could swear we do
invalidname 2y ago
About the GC we can agree to disagree. But about the runtime check out GraalVM which compiles Java to fully native standalone executables.
- jeroenhd 2y ago
  The funny thing about GraalVM is that some workloads are actually slower because of some of the dynamic optimisations the JVM applies. Picking the right garbage collector can make a Java program execute faster than when precompiled to native instructions. I'm sure the same would happen when writing C for the JVM. Tricks like dynamically rearranging/compressing pointers and altering structs to better suit the cache lines and data locality properties of the system code is running on can probably boost any major C program, but that's an incredibly complex change to a C program that the JVM just gives you for free.
snovymgodym 2y ago
Lots of languages that compile to fully native code still have a runtime and a garbage collector as a part of that.
cbm-vic-20 2y ago
I haven't used it, but does GraalVM Native Image take care of that? https://www.graalvm.org/latest/reference-manual/native-image/ https://www.graalvm.org/latest/reference-manual/native-image...

malfist 2y ago

Some would say a garbage collector is an advantage a fully native language doesn't have.

jmartin2683 2y ago
??? There are lots of examples of this.
Jtsummers 2y ago
D, Common Lisp, Go. All natively compiled (or can be in the CL case) with garbage collection.
pfdietz 2y ago
You can bolt a conservative GC onto things compiled by an ordinary C compiler. https://en.wikipedia.org/wiki/Boehm_garbage_collector https://en.wikipedia.org/wiki/Boehm_garbage_collector

caspper69 2y ago

I know HN is not the place for this (because Microsoft), but I really like C#. The ecosystem has been MIT since 2016, and the last few releases have been solidifying the AOT proposition. It just has so many features that allow it to compete with C/C++ on the low level, but it also provides exceptional high level niceties (which admittedly can be slow, some LINQ for example). I know it's not fashionable, especially in a Linux-centric world, but I have used it extensively for many years (on essentially every platform), and it's lightweight (in most instances) and has the features and tooling to make development less stressful. Every time I use Java, it just feels overwhelming and slow.

jeroenhd 2y ago
I like C# too, but both languages seem to perform pretty similarly in my experience. The biggest difference seems to come from third party libraries being more optimized in one framework than the other. Once Project Loom receives some more love (I believe that's scheduled for the next LTS, Java 25) I'll be very interested to see how Java's green threads will compare to C#'s async/await. I think Java's model may help programmers write more optimal code easier, but only if they can pull off their scheduling improvements. C# does have massive advantages when calling native code, though. Java FFI is always just kind of a pain and C# FFI is pretty much trivial.

Jtsummers 2y ago

Garbage collection is orthogonal to "native", by which I take you to mean compiled to native machine code as opposed to something like Java's bytecode compilation or an interpreted language. Go, D, Common Lisp (implementation dependent), and others offer GC and native compilation. If you count automatic reference counting like Objective-C's ARC, you can add it and Swift to the list of natively compiled languages with GC.

superjan 2y ago
I don’t disagree, but I was responding to a claim that the JVM has _all_ the advantages of fully native languages. Fully native allows you to choose to have no runtime, or a garbage collector, and in some environments (realtime, OS kernel, AAA games) that is overwhelmingly the preferred option.
- deleted 2y ago
  [deleted]
- blibble 2y ago
  in Java you can turn off the GC completely and you can also compile to native code
  - shizzy0 2y ago
    You can in theory turn off gc but in practice no one does this because nearly everything is written with the assumption that allocations will be cleaned up by the gc. The compiler has no switches to help you run in a non-gc’d state. At best you can control when you run the gc.
    - blibble 2y ago
      > nearly everything is written with the assumption that allocations will be cleaned up by the gc zero garbage Java it is relatively common in algorithmic trading > but in practice no one does this that's funny, I could swear we do

invalidname 2y ago

About the GC we can agree to disagree. But about the runtime check out GraalVM which compiles Java to fully native standalone executables.

jeroenhd 2y ago
The funny thing about GraalVM is that some workloads are actually slower because of some of the dynamic optimisations the JVM applies. Picking the right garbage collector can make a Java program execute faster than when precompiled to native instructions. I'm sure the same would happen when writing C for the JVM. Tricks like dynamically rearranging/compressing pointers and altering structs to better suit the cache lines and data locality properties of the system code is running on can probably boost any major C program, but that's an incredibly complex change to a C program that the JVM just gives you for free.

snovymgodym 2y ago

Lots of languages that compile to fully native code still have a runtime and a garbage collector as a part of that.

cbm-vic-20 2y ago

I haven't used it, but does GraalVM Native Image take care of that? https://www.graalvm.org/latest/reference-manual/native-image/ https://www.graalvm.org/latest/reference-manual/native-image...