Hacker News Reader

I think your view of history is a bit distorted. In my part of the JVM world (Scala) we've been async for well over a decade. The JVM has supported async / non-blocking IO since nio circa 2003 (https://www.jcp.org/en/jsr/detail?id=51). It was definitely not developed in response to Node or Go.

Straightforward implementations of async are not very ergonomic to use without first class functions, which didn't come to Java till 2014 (Java 8), so that may have held back adoption for Java programmers.

Graal Native Image is more about reducing startup time and memory usage (usually for serverless or command line applications) than async.

As a final note, it's amusing that way before nio, Java actually had user-level / green threads but dropped them: https://en.wikipedia.org/wiki/Green_thread

Yes but was NIO really usable for most tasks? Even with things like Netty to plumb it all the way to web server frameworks, databases and so on took a while. Like if you wanted to do SSL+async then a lot of manual work was required before Loom (if you want to use the stdlib).

Native image isn't related to async for sure. I meant more that it's a feature that people like from Go, which has both AOT/static binaries and also usermode threads.

I can't really comment on the usability of nio as I've never directly used it. I've used many libraries and frameworks that wrapped it up into something more usable. My understanding is that the basic system is quite hard to use, and I guessed at one issue that might contribute to low adoption above (lack of lambda expressions in Java, making callback or promise based libraries tedious to use.)

It's not hard to use exactly but it's low level. My point was that you can't just say "give me an async HTTPS server" or "give me an async JDBC connection", whereas because node started from scratch with this model then it's all async-capable. The new JVM Loom model is better though. No question.

What lost ground?

JetBrains makes tons of money selling IDEs written in Java, the biggest selling mobile OS, is written in a mix of Java and C++, and even Kotlin is heavily dependent on the Java ecosystem.

Alongside two other major IDEs, equally written in Java.

Java is so relevant that even Microsoft, despite its past history with Java, has bought jClarity and become a very relevant OpenJDK contributor, where only Java has day 1 feature parity with .NET, when new Azure capabilities are rolled out.

Most enterprise shops when not doing Java, they are mostly doing .NET, not nodejs, except the Web frontend teams.

He said server side, IDE's and Android are not server side. Java dropped the ball and MS, Node, Google ate their lunch.

Meh.

Only for non heavy or non critical tasks.

No one's going to seriously propose using Node or MS for HFT. Or even use javascript to make something as heavy as a videogame streaming server. It would be too slow. Even if you did do something so quixotic as to build an HFT server in Node, no hedge fund or investment bank is going to switch to a Node based HFT communication system. They'd just be agreeing to be noncompetitive.

I guess what I'm saying is that where it counts, I almost always recommend real time libraries in Java or C++. Rust, is not there yet. Hospitals can't risk a patient's life on it yet by having the PACS system, or God forbid, the modalities themselves dependent on the newest Rust release. Or even worse, Node. It's way too risky.

Most people on HN don't know or hear about work in these kinds of fields. So we think Node is a great and effective tool for solving server side problems. Because it solves most of the problems we see. It's not. It's a great easy tool for solving server side problems. And we'll all make far better CTO's in the future if we recognize the difference, and the revenue opportunity extant, between easy and effective.

I'd love to hear more on this, what are some problems we don't see? And what do you mean by effective?

Hello dreamworld, Google and Microsoft output more Java code per day that you can ever imagine.

Microsoft is again a Java vendor, which I mentioned, and you failed to read.

Android is not Java TM, it still Java the language, and depends on Java the ecosystem.

Server side code regardless of the language is written in Java powered IDEs, that many devs gladly pay money for.

My experience is that most Java people didn't switch to other languages nor to async abstractions. So this will not have people revert lots of work, just improve their existing way of working.

If one's only reading HN it may be easy to think of Java on the decline and almost dead. But I've done lots of greenfield java projects (or, mostly Kotlin, but still on the JVM) various places until recently (when I switched job).

Node is taking the entirely opposite approach to Java and Go, so not sure why you're putting them in the same boat.

Basically what Java is doing now, and what Go did when it came out, is to turn the clock back on (explicit) async/await or promises/futures, and return to simpler threading+blocking IO APIs, while retaining the performance benefits of async code. This is achieved by integrating the blocking IO implementations with the thread scheduler, and by using user-space threads instead of expensive OS threads with their large stacks.

Of course, Java has other threading constructs than Go, but the core idea with Project Loom will be similar: you can just do something like

  int[] xs = new int[N];
  Thread ts = new Thread[N];
  for (int i = 0; i < N; i++) {
    ts[i] = new Thread(
      ()->{xs[i]=blockingRead();}
    );
    ts[i].start();
  } 
  for (int i = 0; i < N; i++) {
    ts[i].join();
  }

Or something close to it, and you will get efficient threading even for large N.

> because it took so long to identify and respond to these moves by competitors

This is and has been Java's explicit strategy since the Gosling days. They watch and wait and implement changes at a glacial pace. They let other languages figure out what works, and implement changes only after they've been demonstrated useful and caveats and pitfalls have been thoroughly explored.

This conservative and deliberate change process permits much better backward compatibility and a level of stability that is very rare among programming languages.

When Java was new it was pretty radical though. At least in the category of mainstream corporate languages. Who else was offering things like an advanced speculating VM, stable/documented bytecode, a huge stdlib, a cleaned up C++ like memory safe language with reflection, sandboxing, applets etc? It was sufficiently radical that MS had nothing like it and felt a need to respond with their own Java impl and later .NET, the UNIX world had nothing like it either and that led Miguel to try and implement .NET for GNOME.

If you compare Java to obscure languages that hardly anyone used outside of the MIT AI Lab then you could argue it was conservative. But that wasn't the space it was playing in.

It feels like this Java as slow-follower idea is actually relatively "new" and more of a response to it slipping from being a relatively futuristic platform in the 1990s to being unable/unwilling to really try new things now.

I wouldn't want to work in an ever evolving always experimental language. Languages that keep changing are annoying and makes your code break. That's time and effort spent not building stuff.

Smalltalk.

Which was hardly experimental in 1996, with IBM VisualAge series of IDEs being written in it, and being the ".NET" of OS/2.

There is a reason why hotspot and most early IDEs trace back to Smalltalk environments, frameworks and culture.

Java was always conservative on the language front, but much more experimental/state-of-the-art on the runtime one, and that is still true today (e.g. GC-wise no other language is even close to Java’s, and basically every research is against that)

> Java was always conservative on the language front, but much more experimental/state-of-the-art on the runtime one

These two things might not be unrelated; a state-of-the art runtime might be necessary to compensate for weaknesses of the language.

> and that is still true today (e.g. GC-wise no other language is even close to Java’s, and basically every research is against that)

For instance, a language which generates less garbage on the heap (instead of boxing nearly everything) would have less need for an advanced GC.

Having to break less due to regenerative breaking in electric cars doesn’t make advancements in breaking technology obsolete - surely, java will get to value types sooner or later that will decrease the amount of allocations, but most programs do make extensive use of the GC fundamentally, so both advancements will improve the language.

The other way to see this is that a powerful runtime allows to write more straight-forward code.

Allocation in the heap allows for much more powerful programming constructs as n object owns it’s own memory layout. Back in 1990 the cost of pointer indirection was virtually free. The need for stack allocation came up only somewhat recently. And the value object model Oracle has come up is infinitely more powerful than what comparable languages are offering.

The trend in performance is allocating more jobs to the runtime. In HPC, this is already the de-facto standard.

This isn't particularly relevant. Java has been very conservative with language changes since at least 8 (2014) but I'd argue 5 (2004) so for the past decade or 2 it has been a conservative language.

And yet, they keep copying Go's (and their own!) mistakes while learning nothing.

Which ones are you talking about?

Loom's focus on fibers/green threads, trying to reuse the Thread API which is as defective as ever.

Please expand on your thoughts. The only defective part of the thread API is the thread group, which nobody ever used anyway.

What?!?

There are companies that use Java and will keep using Java no matter what. A 10+ years old Java is fine for them.

An example: all the incumbent financial sector.

Yes, but there's little growth to be had there. I think the Java guys don't want to be the new COBOL, they'd like new apps to be written in Java too.

Java and, to a lesser degree, C#, seem to have joined COBOL in the list of “forever languages”. Unless financial institutions trust LLMs to rewrite them in newer languages (and finds that cost-effective), there is no way that humongous corpus of business-critical software will ever be ported.

Why not? COBOL has great job security.

I'm told COBOL itself doesn't actually. It's not hard to learn and lots of cheap workers in India will do it for you. The job security is knowing the mainframe tech stack in general, and the specific ways it's used in specific institutions that don't have good internal docs.

And keeps being updated to modern tooling and paradigms.

https://www.microfocus.com/en-us/products/visual-cobol/overv...

COBOL 2023 - https://www.iso.org/standard/74527.html

Late? For what? Lightweight threads weren’t a reason to move to Node or Go. The Loom fibers are very special in that the blocking syntax doesn’t change, there’s no apparent coloring, and you can easily adapt your blocking calls to the lightweight dispatched non-blocking style now. Asynchrony is different from fibers. The .NET team has been pondering introducing fibers when it became obvious that Loom gained significant traction. I don’t think there’s any “lost ground” but simply a healthy competition. It’s not all about the merits of a particular language I think but more about the people behind the ecosystems, the compute platforms and the job market.

As for phasing out reactive streams and Graal, I don’t see why one would ever tread that path.

Why do you think that “isomorphism” is important? Besides, Kotlin Multiplatform, ScalaJS, Vaadin all give you that option.

As for your third paragraph, I think it’s again more of a cultural and job market issue than a purely merits-based technological one. The Node and Go ecosystems gained enough traction to pull in many production apps. The agility story is different with them too. Experienced engineers are very reluctant to changing languages, relearning and rewriting their production apps. Management might prefer to follow whatever they perceive as the present trend but whether they can do their due diligence and justify such a decision financially is a different story. Juniors might be curious enough to rewrite their apps on a different stack. But established software follows different standards. And for the majority of Java software you don’t need the most recent features, it works just fine. Since Java has always been so huge, there’s been a lot of badly designed software (in absolute figures), whose maintainers might be tempted to “rewrite” it in a different stack. But it’s rarely a sane decision. With the new feature set one can now simply opt into certain enhancements, but it’s not an ultimate solution to questionable architectural and design decisions either.

But what do you mean by “Node-style efficiency”? It’s not very performant and is quite a resource hungry platform. I know a couple companies that decided to move from a legacy Spring stack to a modern Node stack. Their argument was like “Java is old and boring, we want to rejuvenate our software by using TypeScript, and one of our principals decided that’s the right call.” Not kidding. In reality though they over-hired JS devs for their frontends and now believe they can profit from that “isomorphy”.

There’s so much expertise behind Java and its ecosystem, most problems solved long ago, something all other platforms can only dream of.

I think we're in agreement :-) I'm talking about how those languages/platforms pitched themselves to get users. In the early days, Node pushed itself as about performance. Write in a high level scripting language like Python or Ruby that you already know, but with a really advanced VM behind you, and with fully async everything so you can handle a bazillion requests simultaneously. That was a winning strategy for them.

Isomorphism was then the other selling point of Node as other platforms caught up. Have one team that can write frontend and backend code, easily share code, easily hire. Yes nowadays you can do that with Kotlin but that's a very new capability (and note: not Java, not Loom). As you say yourself, real companies factor this into their decision making.

Loom solves the performance argument and without losing usability, which is a significant win. But it doesn't help with the other factors and companies like the ones you mention already made their decisions, so, this is what I mean by "late". Those companies probably aren't going to migrate from TypeScript back to Spring are they.

Oh, I wasn’t aware Node had originally pitched performance. Was it only in the context of single-threaded IO?

Yes, from the hiring perspective that “isomorphism” makes a lot of sense on paper.

Pardon me, in your third paragraph, what “other factors” are you referring to?

As for the companies that made such a move, well, it’s their choice. There’s always a reason, it boils down in the end just to whether it was well justified at the moment. Time will tell.

A reasonable argument in my decision making was Spring’s huge memory footprint in a microservices architecture deployed to public cloud. Go’s profile was nigh of 100m peak RSS for a given payload, while Spring’s was 1.5g, per instance. I could just take one commodity nano VM at $5 a month instead of multiple 1g-4g VMs at $50-150 a month each. FinOps. It’s a common theme, suppose you have a service mesh with many tiny services, it does sound right to have them utilize just as few resources and be spawnable instantaneously on-demand. So a mixture of Java and Go services comes up quite frequently.

But then you need to factor in a lot of other costs and the fact that Go’s GC will hiccup anyway and potential goroutine leaks could bring down the entire cluster. And so on. That’s just to say that—on paper—it might look assertive, while in reality you would get to realize that there’s so much opaque minute detail behind the Spring or Quarkus APIs that once you realize that it’s missing in your Go or Node code base and get to reintroduce it (wasting hours), you end up with something that need not perform just as well. The more stuff you plug into your Go or Node lightweight frameworks, the more integrational complexity is on you and the less agile you get. It’s all their choice.

There are ways to minimize JVM resource utilization. And you don’t need to always use Spring, and you can have instantaneous start-up times with persisted app state. To me, it’s getting harder and harder to justify Go or Node on the backend.

> Go’s profile was nigh of 100m peak RSS for a given payload, while Spring’s was 1.5g, per instance.

It's not clear from the context if Java actually needed 1.5G to run, or if it simply just saw there was available memory on the instance and made use of it?

In my experience Java tends to make use of a larger portion of memory than is actually required. This is a good thing in my opinion, as it reduces the work of the GC. You could try running it on smaller instances to see how it performs, if you have not done so already.

No, it was real RSS resource utilization. Basically due to many extra beans being loaded by Spring and extra allocations due to the typical abstractions. If you run it on a smaller instance, your Java process goes out of memory and will have to be restarted. I usually profile all projects thoroughly. You can’t really run a Spring app on less than 512m virtual memory. You can run Java on a few megs, the overhead is negligible over compiled binaries. You can run a lightweight Netty based framework (anything tapir supports essentially) on just 64m heaps. But not Spring. Spring does substantially more work behind the scenes.