Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don’t call it a comeback: Java is still champ

github.com

Post reply on HN
Print view View original

201–210 of 557 posts

Re: Don’t call it a comeback: Java is still champ

#201

Post by neeleshs »

lliamander wrote: post #133
bullen wrote: post #27

The only problem Java has is experienced C programmers don't build servers from scratch with it yet. Once they take that responsibility, the debate will be over because: "While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only…

Erlang is not as peformant as Java, but there are plenty of reasons to prefer the former to the latter: - a much better concurrency model, that gets you parallelism for free just by adding cores - no global gc pauses, low-latency - fantastic operational tools (trace debugging, remote shell, etc.) - Erlang/OTP gives you great middleware out of the box, including including queues, pub-sub, service monitoring, database,…

Biggest benefit with Erlang for me is preemptive scheduling. Has a perf hit, but you don't get brownouts. Java lacks this and this results in hanging threads. A lot monitoring has to be there to detect these conditions . Project loom makes this somewhat better, but at its core, java threads are not preemptible

Re: Don’t call it a comeback: Java is still champ

#202

Post by lliamander »

BenoitP wrote: post #172
lliamander wrote: post #149

Earlier quoted context omitted.

It will take more than green threads to be equivalent to Erlang. Erlang's concurrency model depends upon a completely non-shared memory model, which Java will never have. Edit: and programming it in Java will always be more laborious than in Erlang. Sure, you could put Erlang on the JVM (as the Loom folks want to do) but then is Java really the winner here, or did Oracle just make an alternative BEAM?

Surely having a shared memory model increases the design space? Or is this about memory management performance? A benchmark should settle things in that case. Maybe it will be a draw! Erlang's almost-no-op deallocation vs Java's world-class JIT. Some applications are bound to be better suited to one specific side. I guess we'll see; but it cannot be denied that with Loom Java started to compete on a non-void part of…

Absolutely. And I'm not particularly partisan in this: I like Erlang ( the language in general as well as the concurrency model) and if Java moves closer to that then all the better.

Re: Don’t call it a comeback: Java is still champ

#203

Post by lenkite »

e67f70028a46fba wrote: post #26

The biggest thing Java is missing is full hot swap. Its been implemented via the dcevm but, inexplicably, has been ignored by both sun and oracle. This one, existing technology would make Java DX on par with the dynamic languages

Enhanced hot swap using GraalVM has mostly caught up with capabilities https://www.graalvm.org/22.1/reference-manual/java-on-truffl...

Re: Don’t call it a comeback: Java is still champ

#204

Post by kaba0 »

babypuncher wrote: post #183
bcrosby95 wrote: post #144

Earlier quoted context omitted.

What stuff does C# objectively do better than Java?

Benchmarks generally show C# outperforming Java, but not to a degree that most people would worry about. Performance-sensitive applications are still going to go for something native. One of C#'s biggest assets is Anders Hejlsberg of Turbo Pascal fame. He's been in charge of C# since its inception. He's done a very good job of keeping the language clean and concise, and generally ahead of Java when it comes to adopti…

I would put it differently: C# has a higher performance ceiling due to it having access to lower level controls (mostly value types), but for idiomatic code, there really is no such difference (and if there is any, I would say it goes towards Java). Also, for programs having very dynamic allocation patterns, Java’s GCs are the state-of-the-art and are basically impossible to beat.

Re: Don’t call it a comeback: Java is still champ

#205

Post by kaba0 »

cogman10 wrote: post #189
philipkglass wrote: post #99

Earlier quoted context omitted.

With Java 17 I found that using ZGC eliminated [1] the GC pauses that yield bad P99 latencies without any additional tuning. However, it has lower throughput than G1GC so your P50 advantages will diminish. [1] Reduced them to always well below 1 millisecond.

Which is always the tradeoff with GC. You get to pick latency or throughput and you trade one for the other.

In my experience, this is not related closely to GC and are apparent in many systems. A great book on optimizations explicitly mentions that “improving one aspect of performance may degrade another”.

Re: Don’t call it a comeback: Java is still champ

#206

Post by kaba0 »

nimrody wrote: post #190
plandis wrote: post #107

Earlier quoted context omitted.

Low pause collectors exist explicitly for this purpose. ZGC and Shenandoah both trade throughput (more concurrent collections) for extremely low pause times: https://malloc.se/blog/zgc-jdk16

Does that mean they also trade _memory_ for low pause times? Because, in our application, the memory required for avoiding significant GC pauses is at least 4x the amount of memory we actually need at any given time. This can be significant too.

Have you measured that with ZGC? Because due to using virtual pointers specifically, ”third-party” tools may report higher virtual memory usage than what it actually uses.

Re: Don’t call it a comeback: Java is still champ

#207

Post by the8472 »

lliamander wrote: post #133
bullen wrote: post #27

The only problem Java has is experienced C programmers don't build servers from scratch with it yet. Once they take that responsibility, the debate will be over because: "While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only…

Erlang is not as peformant as Java, but there are plenty of reasons to prefer the former to the latter: - a much better concurrency model, that gets you parallelism for free just by adding cores - no global gc pauses, low-latency - fantastic operational tools (trace debugging, remote shell, etc.) - Erlang/OTP gives you great middleware out of the box, including including queues, pub-sub, service monitoring, database,…

> - no global gc pauses, low-latency

ZGC has sub-millisecond pauses https://malloc.se/blog/zgc-jdk16 And afaik azul's C4 collector has no global pauses, only per-thread pauses (which are also short)

Re: Don’t call it a comeback: Java is still champ

#208

Post by DoesntMatter22 »

nocman wrote: post #63
bullen wrote: post #27

The only problem Java has is experienced C programmers don't build servers from scratch with it yet. Once they take that responsibility, the debate will be over because: "While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only…

> To use anything else (than JavaSE without heavy deps.) on the server is madness. That's a terribly broad generalization. There are multiple other options that are entirely sane.

When all you have is a hammer... What a ridiculous take, most server apps don't use Java and they are just fine.

Re: Don’t call it a comeback: Java is still champ

#209

Post by bhuber »

naikrovek wrote: post #36

and it still enforces terribly strict OOP patterns onto the developer which is almost never the right way to develop software if you care about performance even a little.

I'm not sure you fully appreciate how tailored the JVM, and hotspot in particular, are to executing OOP oriented code. One great example I can think of is polymorphic methods. In C++ for example, you have to explicitly declare a class method as "virtual" in order for it to be polymorphic - i.e. the version called at runtime is tied to the runtime object instance, not the compile time type. This is because in order to do this in C++, there needs to be an extra lookup in the vtable to find the function address for every virtual function call at runtime. If C++ made all its methods virtual, it would take a significant performance hit from the extra vtable lookup for every function invocation.

In Java, all methods are virtual by default. Java also does the equivalent of a vtable lookup at runtime for function calls, but it has something C++ doesn't have - the hotspot optimizer. For any call site that is executed enough to affect runtime performance, the hotspot optimizer will optimize away the vtable lookup if there are only 1 or 2 method versions called at that site at runtime. This is true for the vast majority of cases. For most of the other cases, where you have 3 or more possible method implementations that could be invoked at a given call site, you would probably have to have something like a vtable lookup at that call site whether you use OOP or not (switch statement, if-else, explicit table of function pointers, etc), so you're not losing performance there either. The end result is, the JVM gets polymorphic methods basically for free in terms of performance.

This is just one example, there are many other clever things the JVM does to make OOP code performant. I don't have a citation, but I do recall seeing a talk (maybe by James Gosling?) where he mentioned that one of the primary design goals of Java was to make "doing the right thing" from an OOP perspective also the best option for performance.

Re: Don’t call it a comeback: Java is still champ

#210

Post by gorjusborg »

valbaca wrote: post #136
adrian_b wrote: post #96

Earlier quoted context omitted.

I am not convinced that Java is adequate. I do not know if the problems are related to the Java language or to the typical Java programmers, but Java is the only programming language where I have seen a strong correlation between the programming language used to implement some application and a low quality of that application. During decades of experience with various programs, whenever I was surprised that a program…

I'm with you, even as a Java developer I can immediately recognize when something was written in Java: it's ugly and slow. When it crashes, you know they missed a NPE or tried to use multiple threads.

> I'm with you, even as a Java developer I can immediately recognize when something was written in Java

Sure, if we are talking about desktop applications and we ignore the exceptions (Intellij / Minecraft).

Post reply on HN