Live data from Hacker News

Java 27

mail.openjdk.org

291–300 of 427 posts

Re: Java 27

#291

Earlier quoted context omitted.

Same question for .net or C# Why should anyone use it over Java? Ms is hostile towards its developers, it creates new versions of things, deprecates previous versions, uses confusing naming for newer versions.. etc.

Because your employer is dick-deep in Microsoft psychosis. I've been a .NET dev for a decade now. It's perfectly serviceable, but I wouldn't say I truly love the language anymore, but I would take it over Java any day. Entity Framework and LINQ are gifts from the Gods. I have never used an ORM that even comes remotely close. Also, C# is big in the gaming world. I am working on a game right now, and I was not impresse…

ASP.Net Core is also a pretty good alternative to the ubiquitous nodejs? Especially wherever multi threading is required.

Re: Java 27

#292
post #261

Earlier quoted context omitted.

> the situation is very much the opposite when it comes to Rust. It isn't, and the problem isn't Rust specifically, but all low-level languages. They can offer very good performance (often better than Java) when small. But as they evolve over time, or are very large to begin with, they become much harder to keep performant. This is for pretty fundamental constraints of low-level language that I mention in another com…

> Time and again we see Rust or C++ programs spend 30-50% on memory management. 30-50% of what?

Oh, sorry, missed a few words. Their CPU time.

Re: Java 27

#293

Earlier quoted context omitted.

Go has null pointer dereference problem. Rust is too low-level for typical enterprise app where requirements changes twice a day. You end up spending time and tokens fighting with borrow checker. C# is MS product, which is no-go for some folks. Kotlin probably would be the answer.

> Go has null pointer dereference problem. Which Java famously does not have. > Rust is too low-level for typical enterprise app where requirements changes twice a day. You end up spending time and tokens fighting with borrow checker. In my experience, you do not spend tokens fighting with the borrow checker anymore, newer models are smarter. But it might not be ideal for a lot of CRUD applications. > C# is MS produc…

> Rust is just as ergonomic as any other popular language today if you're using an agent

Have you worked on large (>500KLOC) codebases with an agent? Not only do you have to be an expert at the language, but even if you're lucky and everything is fine, Java code is likely to be particularly fast by comparison, because the agents aren't very good at manual optimisation, especially as the code grows (they're even worse than humans at that, and humans aren't great at manual optimisation of large codebases, either, which is one of the problems the JVM set out to solve; in fact, agent-written code in a low-level language gets pretty slow well below that size). Oh, and the long build times certainly don't help.

Re: Java 27

#295
post #292

Earlier quoted context omitted.

> Time and again we see Rust or C++ programs spend 30-50% on memory management. 30-50% of what?

Oh, sorry, missed a few words. Their CPU time.

Gotcha, that bit makes more sense now. That's quite the statistic!

Re: Java 27

#296
post #5

C# dev here: it’s amazing how different this is from a Microsoft release. First off, Oracle are doing versions at approximately twice the cadence. But also, and I’m guessing this is a function of the much larger Java audience: things rarely get two preview versions in a proper release. Updates in beta versions, yes, all the time. It also feels like Microsoft are bundling a lot more into the platform and leaving less…

Because there is nothing in it, that's why this release, along with majority of the recent ones drop like wet farts. How many previews of the vector API would you like?

Re: Java 27

#297
post #41

Earlier quoted context omitted.

I ported a moderate sized java project to golang. Test suite runs order of magnitude faster now. There isn't much change in terms of the architecture. Pretty much the same algos and data structures. The whole dev tooling runs on a 16 gb mac without swapping now. I used vs code for both

Isn't this mostly about java cold start costs? It might be that other people are optimizing for steady-state performance, not transient startup performance.

One particular test was running for 20 minutes, doing repetitive calculations, hopefully enough to get jitted. It finishes much much faster now. I could have profiled to check what was going on but the test was simple and the dev tooling and the ram usage was a major concern for me. Also gradle upgrades were painful.

Java tooling taking up a lot of ram was a major motivation for me. I have done a lot of Scala as well. I don't think either Java or Scala in the real world beat go on performance for most cases. I don't doubt that in some cases jvm can do better but at least before Valhalla delivers all the promises, in real world, I am doubtful.

I have been a Java/Scala user almost for the majority of my career. I doubt I would pick jvm over golang going forward though. Also not having to deal with OOP is a plus.

Re: Java 27

#298
post #5

C# dev here: it’s amazing how different this is from a Microsoft release. First off, Oracle are doing versions at approximately twice the cadence. But also, and I’m guessing this is a function of the much larger Java audience: things rarely get two preview versions in a proper release. Updates in beta versions, yes, all the time. It also feels like Microsoft are bundling a lot more into the platform and leaving less…

> Java 27: “We’re finished, we’re tired.”

Seems about right

Re: Java 27

#299
post #205

Earlier quoted context omitted.

and the costs they are willing to pay. Go/Rust just kill everything else (except maybe C++) for performance and resource needs. JVM requires so many resources just to run small apps.

Quite the opposite, and the reason is that you can't extrapolate from small programs to large ones. Low-level languages (like C++) incur some significant overheads as they grow large (because of essential constraints of low-level languages that prevent them from doing certain optimisations that matter mostly in large programs), and these are exactly the overheads the JVM is designed to reduce. In small or short-lived…

> Caffeine had the same latency as Moka across all percentiles at twice the throughput.

Caffeine's next release has roughly 25% higher read throughput, with unchanged write throughput, thanks to fixing a false sharing mistake. That won't be visible in real workloads, but is fun nonetheless (500M reads/s on 8 cores).

Re: Java 27

#300

Earlier quoted context omitted.

We have a java monorepo of relatively large size and sophistication, driving our entire fintech, and I haven't seen a NPE for years. Use NullAway and it basically makes the problem go away. Our application won't build if it detects a potential NPE.

Congratulations. You've added another build tool and sprinkled your code with ugly annotations and ifs and Optional Optional.of(x).map(y) all over the place to get the same thing you'd get by moving to Kotlin. I get it why this seems like a less drastic change, but this saddens me. Kotlin solves more issues with the type system (smart casts, reified types, immutability by default), without sacrificing readability. Un…

More Java strawman arguments. How do we live with BuilderFactoryFactoryBuilders! Every day we cry ourselves to sleep!
Post reply on HN