6 ms·

A good step forward and nice that it's in the next (Oracle) LTS version. But is it too late? NodeJS started cleaning up by pushing async-for-all over a decade a

by nvm0n2 3y ago

A good step forward and nice that it's in the next (Oracle) LTS version. But is it too late? NodeJS started cleaning up by pushing async-for-all over a decade ago. Then Go came along and did the same thing but with a simple statically typed language. The Java world developed async server frameworks + GraalVM native image in response and now will be able to incrementally phase them out, but Java lost significant ground server-side because it took so long to identify and respond to these moves by competitors. The question is now whether Java will regain some of that lost ground, or whether people came for the async but stay for the "isomorphism" (same language in both browser and server) / AOT compilation model. My gut says it's not too late for them and devs do engage in a kind of continuous rolling evaluation of platforms. Once Java 21 launches people might start to re-evaluate Java vs Node and once Loom is fully supported in native images, you might start to see people re-evaluate Java vs Go at least. Where by "Java vs" I really mean "JVM languages vs" like with Kotlin, Scala and Clojure as well. Or maybe even Loom will be compatible with GraalJS and then you can do fully blocking programming with Node-style efficiency but on the JVM.

pmontra 3y ago
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.
- nvm0n2 3y ago
  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.
  - rbanffy 3y ago
    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.
  - marginalia_nu 3y ago
    Why not? COBOL has great job security.
    - nvm0n2 3y ago
      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.
    - pjmlp 3y ago
      And keeps being updated to modern tooling and paradigms. https://www.microfocus.com/en-us/products/visual-cobol/overview https://www.microfocus.com/en-us/products/visual-cobol/overv... COBOL 2023 - https://www.iso.org/standard/74527.html https://www.iso.org/standard/74527.html
matsemann 3y ago
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).
noelwelsh 3y ago
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 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 https://en.wikipedia.org/wiki/Green_thread
- nvm0n2 3y ago
  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.
  - noelwelsh 3y ago
    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.)
    - nvm0n2 3y ago
      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.
marginalia_nu 3y ago
> 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.
- nvm0n2 3y ago
  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.
  - marginalia_nu 3y ago
    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.
  - pjmlp 3y ago
    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.
  - 3y ago
deleted 3y ago
[deleted]
jmaker 3y ago
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.
- nvm0n2 3y ago
pjmlp 3y ago
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.
- lambda_dn 3y ago
  He said server side, IDE's and Android are not server side. Java dropped the ball and MS, Node, Google ate their lunch.
  - bilbo0s 3y ago
    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.
    - verdagon 3y ago
      I'd love to hear more on this, what are some problems we don't see? And what do you mean by effective?
tsimionescu 3y ago
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.

by nvm0n2 3y ago

pmontra 3y ago

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.

nvm0n2 3y ago
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.
- rbanffy 3y ago
  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.
- marginalia_nu 3y ago
  Why not? COBOL has great job security.
  - nvm0n2 3y ago
    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.
  - pjmlp 3y ago
    And keeps being updated to modern tooling and paradigms. https://www.microfocus.com/en-us/products/visual-cobol/overview https://www.microfocus.com/en-us/products/visual-cobol/overv... COBOL 2023 - https://www.iso.org/standard/74527.html https://www.iso.org/standard/74527.html

matsemann 3y ago

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).

noelwelsh 3y ago

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 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 https://en.wikipedia.org/wiki/Green_thread

nvm0n2 3y ago
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.
- noelwelsh 3y ago
  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.)
  - nvm0n2 3y ago
    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.

marginalia_nu 3y ago

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

nvm0n2 3y ago
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.
- marginalia_nu 3y ago
  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.
- pjmlp 3y ago
  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.
- 3y ago

deleted 3y ago

[deleted]

jmaker 3y ago

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.

nvm0n2 3y ago

pjmlp 3y ago

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.

lambda_dn 3y ago
He said server side, IDE's and Android are not server side. Java dropped the ball and MS, Node, Google ate their lunch.
- bilbo0s 3y ago
  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.
  - verdagon 3y ago
    I'd love to hear more on this, what are some problems we don't see? And what do you mean by effective?

tsimionescu 3y ago

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.