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

181–190 of 557 posts

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

#181

Post by pdntspa »

hedora wrote: post #142
pdntspa wrote: post #11

I recently started a side new project in Java targetting GraalVM with language version 17. Aside from Java's innate finickyness, it has been an unexpected pleasure. I think a lot of it has to do with its static typing (I typically work in dynamic languages, and it's nice knowing that if the program compiles it likely works), and how simple the language keeps its primitives. But you need really good tooling to use it,…

My main problem with Java is that it's picky, and has some static typing, but it also has heaps and heaps of loopholes in the type system (that turn into runtime exceptions), so it's this weird compromise where everything is substandard. I've found that Go "feels" a lot more like a dynamically typed language, but still has the good IDE support that you're talking about. If you want to see how much progress there has…

I've read enough critiques of Rust to be put off from trying it out at this time. And there's a lot of things I don't like about Go. (Zig is interesting though)

Unfortunately Rust doesn't have the kind of library support that Java does, and I don't really want to roll my own on some things (the side project will never get done if I get lost in the weeds)

For this project the choice fell between Java and C#, and Java won because I was familiar with the library code that does what I want to do.

Besides, Java has Swing, which is about the only cross-platform GUI toolkit I can stand to work with (GTK as a close second)

> but it also has heaps and heaps of loopholes in the type system (that turn into runtime exceptions)

I've yet to run into this in places where I don't really expect it. Do you have some examples of where this becomes a problem? I wrote a bunch of reflection code that triggered a lot of RuntimeErrors, but that was foreseeable as its reflection, the whole point is to figure out types and whatnot during runtime. And at that point, I just fall back to how I write code in dynamic languages.

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

#182

Post by a-dub »

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…

there have been a handful of infrastructure projects in java: kafka and cassandra come to mind immediately, but there are certainly others.

i think what has always sort of steered me away has been a few things:

1) i've long been interested in snappy, interactive and realtime local and server things. and the jvm can do this stuff, but usually it's better suited for server side use where it can be warmed up appropriately. this may also just be a personal dogma that i need to get over.

2) every language and runtime has its quirks where you have to breakdown the illusions of the language itself and understand the internals to get the best performance, but i feel like java is the worst instance of this, where the tricks that people go through in order to control the gc seem excessive.

3) i like simple and concise programs where i feel like the java ecosystem encourages code sprawl. hello world has so much weird stuff and a serious java project has thousands of small source files where computer aided programming (ie. a proper java ide) is not really optional. i find this not only to be unergonomic, but also challenging for being able to quickly understand what a foreign codebase is doing in a short timeframe. maybe it's different from the perspective of a primary developer on one of these large projects though (and possibly quite pleasant).

4) for some reason, i've always liked feeling closer to the metal. even scripting languages "feel" closer because of the jvm abstraction. this is probably also a personal dogma.

> He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector.

people who like java say these sorts of things all the time. i haven't seen a head to head comparison that confirms it though. (although i have not looked). regardless my understanding is that once a jvm is warmed up, it can be quite performant-- and that it has opportunities for live optimization that you don't get in a classic c/c++ runtime.

i don't think c/c++ will be going away as long as operating systems are still written in c. a java operating system seems... strange to me. but that said, i think java has proven itself in terms of high performance application server software.

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

#183

Post by babypuncher »

bcrosby95 wrote: post #144
jeroenhd wrote: post #29

Earlier quoted context omitted.

My problem with Java is that C# exists which does huge portions of the stuff Java excels at just… better. Before, .NET only ran on Windows which disqualified it from many serious applications server deployments. Today, this is no longer the case for everything but cross platform GUI libraries, and even those are an option if you're okay with not having Linux support. It's more akin to the old car you had just before…

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 adopting features like generics and functional programming.

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

#184

Post by bitcharmer »

dboreham wrote: post #124
mabbo wrote: post #122

Earlier quoted context omitted.

That sounds a lot like the complaints about Java from a decade ago. Have you used it lately? Java's GCs are incredible and you have a menu of algorithmic options that let you avoid whatever problem you're worried about.

The JVM GC is fundamentally the same as 10 years ago.

Saying this just shows you don't know much about modern JVM.

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

#185

Post by kaba0 »

sushisource wrote: post #139
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…

> This combined with the fact that Java doesn't crash Huh? Doesn't crash in what way vs. C? I can still deref a null pointer and blow up. Java's perfectly fine, and I have no idea why you'd write C any more, but if you care about (extreme) performance and not crashing, Rust seems the obvious modern choice here.

If you do that in C, your program may run “just fine” on the surface forever, yet it can silently corrupt all of its data. Java can catch NPEs and handle them appropriately (e.g. a web server might just answer server error 500, but it will continue to run with well-defined semantics). I don’t think the two is comparable. Even Rust will go off the happy path with a single use of unsafe, and there is no sailing back from there, while a Java program can’t crash in a UB-like way.

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

#186

Post by notamy »

BenoitP wrote: post #147
haspok wrote: post #114

Earlier quoted context omitted.

Loom does a small fraction of what the Erlang VM is capable of doing. For one, the Erlang VM has built-in preemptive green thread scheduling, which means it can suspend your green thread at ANY instruction, not just when an IO call is in progress. Loom is a step in the right direction, but Erlang is in its own universe for what it was designed for.

> which means it can suspend your green thread at ANY instruction True. Out of curiosity: what's the use case for this? Surely side-effects-out-of-your-system is enough?

> True. Out of curiosity: what's the use case for this?

Scheduling is deterministic, which is a VERY useful property to have. See ex. http://erlang.org/pipermail/erlang-questions/2006-December/0... about changing scheduler determinism.

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

#187

Post by pushingice »

NoSorryCannot wrote: post #10
falcolas wrote: 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…

Whoever invented the car analogy should pay for what they did.

The car analogy is the Ford Model T of analogies.

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

#188

Post by mcculley »

sushisource wrote: post #139
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…

> This combined with the fact that Java doesn't crash Huh? Doesn't crash in what way vs. C? I can still deref a null pointer and blow up. Java's perfectly fine, and I have no idea why you'd write C any more, but if you care about (extreme) performance and not crashing, Rust seems the obvious modern choice here.

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 whatever I can to test and develop the system and find more bugs without restarting the whole thing.

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

#189

Post by cogman10 »

philipkglass wrote: post #99
nelsondev wrote: post #56

Earlier quoted context omitted.

The p50 speed up from delaying memory management comes with a trade off, namely you get Garbage Collection pauses, bad p99, and spend your effort tuning the Garbage Collector instead of your code.

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.

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

#190

Post by nimrody »

plandis wrote: post #107
nelsondev wrote: post #56

Earlier quoted context omitted.

The p50 speed up from delaying memory management comes with a trade off, namely you get Garbage Collection pauses, bad p99, and spend your effort tuning the Garbage Collector instead of your code.

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.

Post reply on HN