Hacker News Reader

Comment by superjan | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

> Fully native allows you to choose to have no runtime, or a garbage collector,

Are you quite sure of that? I think you're getting stuff mixed up here. AFAICS, a native-compiled language might very well have mandatory garbage collection. Not that any such language immediately springs to mind, and I'm not even sure any do actually exist, but surely they could exist. The concepts "native compilation" and "garbage collection" are, AIUI, orthogonal.

There were/are a bunch of Java to native compilers.

in Java you can turn off the GC completely

and you can also compile to native code

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.

> 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

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

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

You can bolt a conservative GC onto things compiled by an ordinary C compiler.

https://en.wikipedia.org/wiki/Boehm_garbage_collector

??? There are lots of examples of this.

D, Common Lisp, Go. All natively compiled (or can be in the CL case) with garbage collection.

I haven't used it, but does GraalVM Native Image take care of that?

https://www.graalvm.org/latest/reference-manual/native-image...

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

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.

Reply on news.ycombinator.com