[jeffbee]

Java is one of the giants and there are tons of existing and new projects that use it. Hotspot is the choice for high performance programs. Approaching its performance even with C++ requires a dedicated team of experts. Look at QuestDB, or Netflix, as current examples of projects choosing Java.

The languages that get a lot of airtime on HN like Rust, Go, and OCaml are way down in a tier of languages that get a lot of blog posts but enjoy relatively little traction in reality.

[haberman]

> Hotspot is the choice for high performance programs. Approaching its performance even with C++ requires a dedicated team of experts.

It's very surprising to hear you say this, as it's so contrary to my experience.

From the smallest programs (Computer Language Benchmarks Game) to pretty big programs (web browsers), from low-level programs (OS kernels) to high-level programs (GUI Applications), from short-lived programs (command-line utilities) to long-lived programs (database servers), it's hard to think of a single segment where even average Java programs will out-perform average C, C++, or Rust programs.

I hadn't heard of QuestDB before, but it sounds like it's written in zero-GC Java using manual memory management. That's pretty unusual for Java, and would require a team of experts to pull off, I'd think. It also sounds like it drops to C++ and Rust for performance-critical tasks.

[jeffbee]

It's a statement of my experience in the performance achieved in practice by real developers who lack dedicated language support teams. And even the ones who enjoy dedicated language support teams. I could point to gRPC. gRPC-Java is slapping gRPC-C++ sideways. Why is that? Because when a codebase is increasingly complex, the C-style lifetime management becomes too difficult for developers to ponder, and they revert to relying on the slower features of the language platform, like reference counting smart pointers.

I think hybrid implementations, where a project enjoys the beneficial aspects of the language runtime at large, but delegates small, critical functions to other languages, makes sense. That keeps the C, C++, or Rust stuff contained to boundaries that are ponderable and doesn't let those language platforms dictate the overall architecture of the program.

[ahefner]

If gRPC overhead is critical to your system, you've probably already lost the plot on performance in your overall architecture.

You make a fair point about smart pointers, and median "modern C++" practices with STL data structures are unimpressive performance-wise compared to tuned custom data structures, but I can't imagine that idiomatic Java with GC overhead on top is any better.

[dangus]

The languages that get a lot of airtime on HN are the ones the young people will just use by default.

Hotspot is the current choice for high performance programs, but is Rust lower performance in some way or are the only downsides related to its younger age?

It’s perhaps useful look at what languages brand new projects are being started with rather than just looking at what languages large established companies like Netflix are choosing.

[jeffbee]

Rust is not inherently slower but then again neither are C and C++, but in practice all of those tend to be less efficient than realistic Java systems. Rust is displacing C in contexts where Rust's less than amazing performance are not noticeable in contrast to C's also-not-amazing level of performance. And I also think there is a cognitive bias under which a developer will reach for Rust to supplant a legacy C program, because that developer reflexively dislikes managed language runtimes.

[kakacik]

Depends where you are, in startup world definitely yes. Elsewhere, not so much.

Companies couldn't care less about the underlying platform or language, they want reliability, stability and tons of easy to find people who can work with it from Day1. Java delivers all that, and will keep delivering for upcoming decades. Big businesses and big money love this (or hate the least out of IT stacks).

[ecshafer]

The fact of the matter is that you read through a lot of these start up blogs on how they scaled X technology to some amazing number like 1000 users a day or whatever. But your average Java Spring app on Postgres is doing some far heavier workloads.

[TuxSH]

Go is a bad example since it's ubiquitous in the Kubernetes world, in particular with k8s "operators" (for a variety of reasons)