Hacker News Reader

Comment by jasode | Hacker News Reader

>Sure, Java was slow and clunky but at least it was free of the memory unsafety that plagued C/C++. What was the mainstream "safe" alternative? There was no Rust back then,

Before Sun Java in 1995, companies built enterprise CRUD apps with "safe" memory languages using MS Visual Basic, PowerBuilder, and xBase languages like dBASE and FoxPro. This allowed them to develop line-of-business apps without manually managing memory in C/C++.

View on HN

On top of that, when I last had the misfortune of using Java, (17, maybe?) the GC still was a top cause of production outages and a massive productivity drag.

They claimed they fixed it a dozen times, starting with JDK 1.4, and continued to claim that with every major release since.

Java might be memory-safe. But it is "performance-unsafe".

For certain problems. I'm looking forward to Project Valhalla finally landing, and the subsequent improvements that come later.

Getting the performance benefits of data oriented programming patterns is very exciting to me for allowing Java to run totally different classes of applications than haven't been practical until now.

Valhalla is indeed the one effort that could close the biggest gap with native languages. Java Vs C or Rust for networked applications have comparable CPU utilisation with comparable throughput, but memory consumption can be >100x. Project Valhalla is the only thing that could potentially change that. The problem I do see is that even after the language and JVM have value types, the vast extense of libraries that people use are unlikely to change to leverage them. But for projects that control most of their own dependencies, it will be a clear win.

I think over a few years, most of the major dependencies will adopt some of the benefits of Valhalla; at least in the performance sensitive parts.

It's perfectly fast. Slower than C/C++ under most scenarios, but not by a particularly large amount, and in some scenarios faster due to optimisations only possible from dynamic runtime observation.

Top cause for production outages? Like what, did you get OOM errors? Also, how can a GC be a productivity drag?

Anyways, besides your very questionable "experience" with java, it literally runs half of the internet, and has by far the most mature and performant GC out of any platform, no one else is even close in this category.

How the heck did you manage that? I've been working on two major clouds for well over a decade, both built primarily on Java, and not seen a single production outage caused by garbage collection. Not one.

Not even S3 in us-east-1 at its gobsmacking RPS rates had issues with garbage collection.

No special coding approaches were taken to achieve that, just standard stuff.

Reply on news.ycombinator.com