Live data from Hacker News

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

github.com

251–260 of 557 posts

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

#251
post #209

Earlier quoted context omitted.

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…

it doesn't matter how much the HotSpot JVM is tailored to OOP code. CPUs and RAM are not tailored to OOP in any way. Procedural code will always be more efficient with CPU and RAM, arrays will always be faster than Lists, being able to control datatype sizing to the byte will always outperform classes, and so on. java is very fast, please do not misunderstand me. java is much better than it used to be, as well. Java…

> it doesn't matter how much the HotSpot JVM is tailored to OOP code

This is obviously false. The JVM, or any other compiler for that matter, is what translates the OOP code into CPU instructions. If it does that optimally, it won't matter what design pattern the top-level compiled language used. If it does it poorly, then it will.

> CPUs and RAM are not tailored to OOP in any way.

This is not entirely true. Intel in particular pays a lot of attention to Java performance when benchmarking processor designs, see for example https://www.intel.com/content/www/us/en/developer/articles/t... .

> Procedural code will always be more efficient with CPU and RAM...

First of all, arrays vs Lists and data type sizing are orthogonal to procedural vs OO code. You can write OO code that uses arrays and procedural code that uses lists, and datatype sizing is more related to your choice of language and compiler toolchain than your design patterns.

I think what you're trying to say here is that the performance ceiling for a low level language using simple language primitives (if-else and vanilla function calls instead of classes and polymorphism) that compiles to a binary is higher than that for a high level language that compiles to an intermediate language (or an interpreted language). This is generally true for small code paths - if you need to do a bunch of matrix operations, or data crunching for a small well defined problem, you can generally do it faster in C/C++ than in Java if you put in enough effort. The ceiling part matters though - in general, you have to put in a lot of skill and development effort to realize these differences, and this often grows super-linearly with the size of your codebase for low level languages. If you have a large application that has a lot of code, your overall performance will usually be higher with a high level language because the average performance for any particular part will be much better. Sure, given infinite time and resources you could theoretically do better in C, but nobody has that.

This is reflected in the approach most professionals take in practice when it comes to perf optimization - write most of your code in a high level language like Java or Python because on average it will be faster and less buggy for any reasonable amount of developer effort. For pieces of code that absolutely have to run as fast as possible, write them in C and call out to them from the high level language.

I guess the point I'm trying to make here is lots of people choose java precisely because performance is a concern. It does better than most other high level languages out there, and your average performance for a large codebase will be much better than something like C/C++ given the same amount of effort. As others have noted, it does multithreading better than most too, which is another major performance consideration. I don't care if my Java code is half the speed of the C equivalent if I can easily run 40 cores at once - or 40000. I think languages like Rust and Swift may let us have the best of both worlds in the future, but that remains to be seen. For now, the only time lower level procedural languages win is when you need a relatively small codebase to run absolutely as fast as possible.

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

#252

Earlier quoted context omitted.

> - 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)

Low pauses, low memory overhead, low CPU overhead. In Java world, pick one. In C/C++/Rust/Zig you can have all three at once.

Add memory safety to the list. And allow to select only 3.

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

#254

Earlier quoted context omitted.

I have worked on big projects with up to ~100 developers. On the C projects, someone's null-pointer dereference brings down the whole process. On the Java projects, the event handler or daemon thread has an exception handler at the top that logs the error and keeps executing. This is a huge difference in behavior. Sometimes, you want to fail fast and be forced to fix that bug. More often, I want to keep doing whateve…

You can have a null pointer handler in C as well. But this is generally not a good idea. I find software that does not crash early and visibly but instead tries continuing despite an obvious bug very brittle and often causing trouble because it can take a long time before operators notice the problem. If you accumulate enough bugs of this type, you get a mess that "kinda works" but is full of surprises.

Yeah, I implemented an “atcrash” handler as a library which I embedded into multiple projects. But it was only so I could walk the stack, dump a stack trace into the terminal, and tell the user, “Please email this to the developer.” And then as cleanly as possible shut down the process. In C, as you say, not much else can be safely done.

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

#255
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…

The only problem Java has is experienced C programmers don't build servers from scratch with it yet. Please explain. What kind of crazy jack write servers in C? (Real question, trying to learn here)

The developers of apache httpd, nginx, postgresql, redis, among many others?

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

#256
post #5

Java's adequate. It's like a Toyota Corolla (insert your boring car of choice here if you don't feel this one works for the analogy). Not the prettiest, not the fastest, not the most efficient. But it gets you from point A to point B with little fuss or muss. I totally get why companies adopt and standardize on it. Do I use it for personal projects? Nope. Because it's not fun to "drive". For that, I pick the equivale…

> It's like a Toyota Corolla This is only an invitation to car-shedding!

So it was. So it was indeed.

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

#257

Earlier quoted context omitted.

Car analogies aren't intrinsically bad, they are just the go-to analogy when someone wants to jam an analogy where it isn't needed. Analogies in general should be used sparingly, and only in an explanatory setting. Instead people use them as a rhetorical device in arguments, which usually reduces the argument to arguing about the analogy (and you can usually shuffle around the parts of an analogy to flip the meaning…

> Car analogies aren't intrinsically bad What can I say? They get me from claim A to claim B. So are you saying that analogies should only be used like secondary steering wheels?

They only get you from claim A to claim B when there is enough traffic to invest in roads and if people follow the rules.

A more versatile set of analogirs are of course ATVs, Aircraft, or even the humble legs.

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

#258
post #252

Earlier quoted context omitted.

Low pauses, low memory overhead, low CPU overhead. In Java world, pick one. In C/C++/Rust/Zig you can have all three at once.

Add memory safety to the list. And allow to select only 3.

But that's not performance category. And, btw, Rust has all 4 of them. If we're talking about safety guarantees then let's add data race freedom to the mix. Or use-after-free protection for non-memory resources. ;)

Java is cool language and has many nice features, but its type system is not its major advantage.

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

#259

Trouble with java is that it does not scale up or down in terms of ram. Minimum RAM for a sever doing something normal over tcp is measured in gigabytes. Big servers > 16gb get difficult to manage at runtime. You have to scale with more VMs. You can write useful C servers that are very small, especially if you compile with musl. And run the same code for 1000kcc (not a typo) When you have big arrays of memory storing…

kcc in this context is "kilo clock cycles", right?

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

#260
Java was actually not bad for me in class when learning software design and data structures, but soul-crushing to work with in the real world. Mindless, unnecessary use of getters/setters, interfaces, and AbstractFactoryImpls. Hiding almost every piece of functionality behind 10+ layers of indirection. Dependency Injection with Spring. They all make it feel like Java draws folks who actually __enjoy__ writing bloated, over-engineered garbage.

YMMV, of course, and yes, there are modern frameworks other than Spring (Play is supposedly pleasant to work with), but life is too short to try to sort out that mess.

I plan to stick to Elixir as much as I can, for as long as I can. When the language clicked for me, it was the biggest breath of fresh air since I decided to pursue programming as a profession, and even cooler than when I discovered Python/Django.

Edit: obviously, Java is not all bad, and not all (or even most) people who use it fit the description above. But something about the ecosystem seems to draw those types (no pun intended) disproportionately.

Post reply on HN