Live data from Hacker News

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

github.com

191–200 of 557 posts

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

#191
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.

10 years ago the algorithms you could pick were serial, parallel, and CMS.

Today we've removed CMS, added G1GC, and added ZGC.

G1GC is similar to the parallel in the way it operates but is divided up enough to control for latency.

ZGC is fundamentally different from the parallel collector or G1GC. Suggesting it is the same is to suggest you know nothing of the changes that have happened.

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

#192

Earlier quoted context omitted.

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

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?

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

#193
post #93

Earlier quoted context omitted.

Who stopped what? Java 19 is the upcoming release.

using the parent comments naming scheme it is actually 1.19, I don’t know why they stopped developing major releases however.

The real nightmare is Java's versioning scheme

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

#194
post #45

Earlier quoted context omitted.

I think people dislike XML precisely because it's so flexible and unopinionated. It means that when you're parsing a new XML source, you have to look for data that might be encoded in two or three little niches. God help you if it's encoded in each of them, and if the data therein is contradictory. Basically, it's easy to "hold it wrong" in a way that harms consumers.

> I think people dislike XML precisely because it's so flexible and unopinionated. You're probably right. > Basically, it's easy to "hold it wrong" in a way that harms consumers. I feel a bit like this could equally apply to things like GraphQL. I spend more time reading the docs on how someone's internal data model is built than I do writing GraphQL queries. And if I get that data model slightly wrong, my query's ga…

Over-engineering (relative to the complexity of the task you want to solve).

Enterprise solutions are often so complex and generic that they can theoretically do and interoperate with anything, but are also hard to get started with and use well.

People like to start with simple things and expand from there instead of buying a whole house when they just want a sink (am I using the phrase right?). In my opinion this makes a lot of because it avoids unnecessary complexity and sensitizes people to why some complexity is in fact necessary.

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

#195

Earlier quoted context omitted.

Corollas don't come with all sorts of weird (now aging) buzzword-driven preferences like nudging you towards xml, factories, etc.

Personal rant: I've never understood the hate towards XML. It's a practical and flexible markup language that does not depend on whitespace or quoting every bloody thing. Plus, every markup language invented since has had to re-invent XML things that, surprise surprise were actually needed. Paths, schemas, comments, etc. I get frustrated with JSON because of things I could do in XML that I can't do in JSON without br…

Once upon a time I was deeply in the world of XML Schema, XSLT, and XQuery. It was actually pretty cool.

But using complex, poorly specified, possibly Turing-complete "config" files written in a markup language that isn't the primary language your app is written in is a serious code smell.

It means you would either be better off using an embedded scripting language (like Groovy) or a better core language.

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

#196
post #122

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.

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.

> Java's GCs are incredible and you have a menu of algorithmic options

can these options be used in separate parts of a single app ? e.g. the app I'm developing in C++ has parts that do realtime audio, others that do GPU rendering, others that do classic Qt Widgets GUI, others that do offline computations on datasets - and they all have different performance characteristics and need different memory management schemes to get the best out of each, all while being in a single process; there's reference counting, tree-based allocation, pooled, linear, a GC-ish thing which ensure that memory is freed in specific non-realtime threads... Can that be done with Java or is one tied to a single GC implementation for a given execution of a process?

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

#197
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!

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

#198
post #154

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.

> tuning the Garbage Collector instead of your code. This is a feature, not a bug. Which is riskier?

Now-a-days, if you are tuning your GC you are almost certainly doing the wrong thing.

While the JVM offers a plethora of levers to pull in case you are hyper concerned about different things, the heuristics are VERY good. Mucking with the fine grained details can disable heuristics and ultimately give you worse results than if you just left stuff alone.

The levers to pull are algorithm, max memory, and max pause time. All other levers should be left alone unless you've got GC logs to back up what you think needs changing. (And even then... Do you really?)

Typically, the better route is flight recorder and eliminating wasted allocations.

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

#199
post #93

Earlier quoted context omitted.

Who stopped what? Java 19 is the upcoming release.

using the parent comments naming scheme it is actually 1.19, I don’t know why they stopped developing major releases however.

But that is not the java naming scheme. Java stared using normal major version numbers back in the Java 5 days. They've developed major releases continuously for decades.

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

#200

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…

It's certainly a trade off. One thing erlang can do which java cannot is survive one of it's actors OOMEing. That kills the actor and not the VM.

That comes at some extreme costs and implications to what the VM is capable of achieving, but it is something that's pretty impressive.

Post reply on HN