5 ms·

It's been a while since I've programmed in Java. I wonder how good the concurrency stuff is these days. On a somewhat related note I was talking to a team from

It's been a while since I've programmed in Java. I wonder how good the concurrency stuff is these days. On a somewhat related note I was talking to a team from a random bay area company on how they switched from Java/Spring to Node and that Node is slower but since it's single threaded they load balance a bunch of servers and in practice it's just as fast when considering the developer productivity. Compute is really cheap these days, so I wonder how much it's worth it to squeeze every drop of performance out now.

marginalia_nu 4y ago
Compute is cheap if you're doing trivial things that doesn't require much compute. Flip side is that this is true for everyone. If you're only doing trivial things that could have been done 20 years ago, you really don't have much competitive advantage. It's difficult to be competitive in the area of solving easy problems.
- CharlieDigital 4y ago
  > Compute is cheap if you're doing trivial things that doesn't require much compute. A lot of the work on the web/API side is I/O bound (e.g. waiting for network I/O to database) so unless throughput is your game (e.g. Stackoverflow), it seems that Node is "good enough" for most web/API work.
  - marginalia_nu 4y ago
    It is I/O bound because you aren't using the available compute as much as you could. Modern hardware is insanely powerful. Like it's absolutely bonkers how much you can do on a modern computer. Although most modern applications have capabilities on par with a 2006 flash game.
    - CharlieDigital 4y ago
      All true, but there's a point of nuance: because cloud is all virtualized, you are taking advantage of the underlying high performance modern hardware because a serverless Node function is one of who know how many on the physical hardware.
- bombcar 4y ago
  The vast, vast majority of "business code" even at startups and unicorns like AirBNB and Uber is not doing "compute-bound" things. They're all basically fancy CRUD apps.
  - marginalia_nu 4y ago
    Yeah, you can do more though, is my point. The CRUD market is pretty crowded. Feels like a lot of the AI hype is the sudden discovery that modern computers are actually pretty fast and squandered doing book-keeping in small-to-medium SQL tables (not that you need LLMs to do interesting things with them). Basically anything that required a data center in the year 2000 you can do on a powerful desktop PC today.
    - cutler 4y ago
      Yes, back in 2004 DHH created Rails on an 800Mhz PPC iBook with 256Mb RAM and launched Basecamp for the first year on a server with the same amount of RAM. A bargain basement VPS comes with 4 times the RAM these days.
  - cutler 4y ago
    Uber - are you kidding? Their shortest route algorithms are extremely CPU-intensive.
    - isbvhodnvemrwvn 4y ago
      And how much of their codebase is this? 0.5%, if that?
- imtringued 4y ago
  Compute is cheap if you only run one program on your computer. The moment two or more "compute is cheap" programs run on a computer is the moment when cheap is not so cheap anymore. Nothing like IntelliJ crashing during a video conference and then indexing your entire project from scratch... Encoding video in real time is CPU intensive, indexing a hundred libraries adds oil into the fire.
RedShift1 4y ago
They are using the cluster module right? https://blog.appsignal.com/2021/02/03/improving-node-application-performance-with-clustering.html https://blog.appsignal.com/2021/02/03/improving-node-applica...
foepys 4y ago
> Compute is really cheap these days, so I wonder how much it's worth it to squeeze every drop of performance out now. And that's why every single Electron app is slower on a modern 4.7 GHz 8 core CPU than a (although not as pretty) native app on a single core CPU in 1999. Spotify is slow as molasses and has less features than foobar2000, MS Teams is slower than any messenger I used in 2005, and all those Postman-like apps are just a horror to use compared to a simple bash script with wget. Case in point: I cannot use MS Teams on my state of the art computer when I'm compiling. It's just so slow to type and switch chats.
- vosper 4y ago
  > and all those Postman-like apps are just a horror to use compared to a simple bash script with wget. Personally I like having collections of requests, automatic formatting of responses, dedicated fields to enter headers into, automatic parsing of cURL / HAR etc, the ability to generate code in various languages... There's a lot more to most of these Postman-like apps than just making requests! Though I have seen Insomnia just completely choke up on large responses (10s of MBs) that Sublime renders in a flash - so you're not completely wrong, just throwing the baby out with the bathwater :)
Traubenfuchs 4y ago
> I wonder how good the concurrency stuff is these days. What were you missing? Java had threading, task, threadpool capabilities for ages. It comes with all kinds of concurrent collection classes and running something in parallel could be just one .parallelStream() away. There are also countless reactive frameworks that minimize thread count. Java Loom / green threads are available since Java 19 (hidden behind a flag).
- endisneigh 4y ago
  Sorry, I meant in terms of developer ergonomics and ease of use, not purely compute performance.
  - winrid 4y ago
    The Reactive java frameworks are way more developer ergonomic than NodeJS if you use the virtual threads previews, otherwise you have to use callbacks/futures. But at least you have runtime type checking... Vertx is way better than Node in a lot of ways, and faster, and easier to debug. Lock the event loop? You immediately get a log that you did something bad.
    - winrid 4y ago
      Like I just got an error in my IDE with TypeScript "ChartConfiguration is not generic". So I cmd+click into the type definition and it's a ChartConfiguration<T>. okay... The whole ecosystem feels super fragile. It hurts productivity and moral. This just doesn't happen with Java.
NERD_ALERT 4y ago
It's about to get much better once Project Loom is ready. This will introduce virtual threads and structured concurrency. https://developer.okta.com/blog/2022/08/26/state-of-java-project-loom https://developer.okta.com/blog/2022/08/26/state-of-java-pro...
throw0101a 4y ago
> Compute is really cheap these days, so I wonder how much it's worth it to squeeze every drop of performance out now. "What Andy [Moore of Intel] giveth, Bill [Gates of Microsoft] taketh away." * https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law See also: > Wirth's law is an adage on computer performance which states that software is getting slower more rapidly than hardware is becoming faster. * https://en.wikipedia.org/wiki/Wirth%27s_law https://en.wikipedia.org/wiki/Wirth%27s_law
ithrow 4y ago
Genuine question, why developer productivity was higher in node?
SillyUsername 4y ago
Node is much simpler to work with, and if you're running one shot, short serverless ops (i.e. not batch), faster to start (no JVM cold start) and cheaper to run (less RAM) than Java. If they're really concerned about performance they'd not go wrong by using Deno which often has at least double the performance of Node https://medium.com/deno-the-complete-reference/node-js-vs-deno-vs-bun-server-side-rendering-performance-comparison-f80a5abc766f https://medium.com/deno-the-complete-reference/node-js-vs-de... Deno for a lot of operations is actually comparable to Java level performance: https://programming-language-benchmarks.vercel.app/java-vs-typescript https://programming-language-benchmarks.vercel.app/java-vs-t...
- fidgewidge 4y ago
  Of course there is cold start. Both Node and Deno use JIT compilation just like regular Java, which means they warm up. JS code will use more RAM than Java for equivalent constructs, not less. You may be fooled though, by the way that the JVM by default will use free RAM rather than burn energy/CPU collecting garbage when it doesn't need to. So it will look like your app is using a lot of RAM but in reality the JVM will give it up when asked.
  - SillyUsername 4y ago
    My experience of paying for cloud services does not back that up. Java AWS Lambdas are typically 2-3x heavier in memory usage than a TS/JS equivalent, and the benefit of that warmup is negated if the Lambda shuts down due to idle time. "Give it up when asked" !== less streamlined, it means expanding heap is required for normal operation. Too little heap, it buckles, GC is almost constant, and performance goes out of the window.
    - fidgewidge 4y ago
      That's inherent to any GC algorithm. More CPU time = less RAM usage because garbage is collected more aggressively. I don't understand why you think that JS, a JIT compiled GC'd language, doesn't warm up and doesn't have to trade off GC time vs memory.
fidgewidge 4y ago
> Node is slower but since it's single threaded they load balance a bunch of servers and in practice it's just as fast when considering the developer productivity This sentence doesn't make any sense. It can't be both slower and just as fast, developer productivity is a totally different concept to performance. And being single threaded just means you have to spend more RAM to saturate your CPUs (threads are cheaper than processes), nothing stops you running many single threaded JVMs and load balancing across them, it's just inefficient.
krzyk 4y ago
> just as fast when considering the developer productivity I wouldn't use Javascript and developer productivity in the same sentence.

marginalia_nu 4y ago

Compute is cheap if you're doing trivial things that doesn't require much compute. Flip side is that this is true for everyone. If you're only doing trivial things that could have been done 20 years ago, you really don't have much competitive advantage. It's difficult to be competitive in the area of solving easy problems.

CharlieDigital 4y ago
> Compute is cheap if you're doing trivial things that doesn't require much compute. A lot of the work on the web/API side is I/O bound (e.g. waiting for network I/O to database) so unless throughput is your game (e.g. Stackoverflow), it seems that Node is "good enough" for most web/API work.
- marginalia_nu 4y ago
  It is I/O bound because you aren't using the available compute as much as you could. Modern hardware is insanely powerful. Like it's absolutely bonkers how much you can do on a modern computer. Although most modern applications have capabilities on par with a 2006 flash game.
  - CharlieDigital 4y ago
    All true, but there's a point of nuance: because cloud is all virtualized, you are taking advantage of the underlying high performance modern hardware because a serverless Node function is one of who know how many on the physical hardware.
bombcar 4y ago
The vast, vast majority of "business code" even at startups and unicorns like AirBNB and Uber is not doing "compute-bound" things. They're all basically fancy CRUD apps.
- marginalia_nu 4y ago
  Yeah, you can do more though, is my point. The CRUD market is pretty crowded. Feels like a lot of the AI hype is the sudden discovery that modern computers are actually pretty fast and squandered doing book-keeping in small-to-medium SQL tables (not that you need LLMs to do interesting things with them). Basically anything that required a data center in the year 2000 you can do on a powerful desktop PC today.
  - cutler 4y ago
    Yes, back in 2004 DHH created Rails on an 800Mhz PPC iBook with 256Mb RAM and launched Basecamp for the first year on a server with the same amount of RAM. A bargain basement VPS comes with 4 times the RAM these days.
- cutler 4y ago
  Uber - are you kidding? Their shortest route algorithms are extremely CPU-intensive.
  - isbvhodnvemrwvn 4y ago
    And how much of their codebase is this? 0.5%, if that?
imtringued 4y ago
Compute is cheap if you only run one program on your computer. The moment two or more "compute is cheap" programs run on a computer is the moment when cheap is not so cheap anymore. Nothing like IntelliJ crashing during a video conference and then indexing your entire project from scratch... Encoding video in real time is CPU intensive, indexing a hundred libraries adds oil into the fire.

RedShift1 4y ago

They are using the cluster module right? https://blog.appsignal.com/2021/02/03/improving-node-application-performance-with-clustering.html https://blog.appsignal.com/2021/02/03/improving-node-applica...

foepys 4y ago

> Compute is really cheap these days, so I wonder how much it's worth it to squeeze every drop of performance out now. And that's why every single Electron app is slower on a modern 4.7 GHz 8 core CPU than a (although not as pretty) native app on a single core CPU in 1999. Spotify is slow as molasses and has less features than foobar2000, MS Teams is slower than any messenger I used in 2005, and all those Postman-like apps are just a horror to use compared to a simple bash script with wget. Case in point: I cannot use MS Teams on my state of the art computer when I'm compiling. It's just so slow to type and switch chats.

vosper 4y ago
> and all those Postman-like apps are just a horror to use compared to a simple bash script with wget. Personally I like having collections of requests, automatic formatting of responses, dedicated fields to enter headers into, automatic parsing of cURL / HAR etc, the ability to generate code in various languages... There's a lot more to most of these Postman-like apps than just making requests! Though I have seen Insomnia just completely choke up on large responses (10s of MBs) that Sublime renders in a flash - so you're not completely wrong, just throwing the baby out with the bathwater :)

Traubenfuchs 4y ago

> I wonder how good the concurrency stuff is these days. What were you missing? Java had threading, task, threadpool capabilities for ages. It comes with all kinds of concurrent collection classes and running something in parallel could be just one .parallelStream() away. There are also countless reactive frameworks that minimize thread count. Java Loom / green threads are available since Java 19 (hidden behind a flag).

endisneigh 4y ago
Sorry, I meant in terms of developer ergonomics and ease of use, not purely compute performance.
- winrid 4y ago
  The Reactive java frameworks are way more developer ergonomic than NodeJS if you use the virtual threads previews, otherwise you have to use callbacks/futures. But at least you have runtime type checking... Vertx is way better than Node in a lot of ways, and faster, and easier to debug. Lock the event loop? You immediately get a log that you did something bad.
  - winrid 4y ago
    Like I just got an error in my IDE with TypeScript "ChartConfiguration is not generic". So I cmd+click into the type definition and it's a ChartConfiguration<T>. okay... The whole ecosystem feels super fragile. It hurts productivity and moral. This just doesn't happen with Java.

NERD_ALERT 4y ago

It's about to get much better once Project Loom is ready. This will introduce virtual threads and structured concurrency. https://developer.okta.com/blog/2022/08/26/state-of-java-project-loom https://developer.okta.com/blog/2022/08/26/state-of-java-pro...

throw0101a 4y ago

> Compute is really cheap these days, so I wonder how much it's worth it to squeeze every drop of performance out now. "What Andy [Moore of Intel] giveth, Bill [Gates of Microsoft] taketh away." * https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law See also: > Wirth's law is an adage on computer performance which states that software is getting slower more rapidly than hardware is becoming faster. * https://en.wikipedia.org/wiki/Wirth%27s_law https://en.wikipedia.org/wiki/Wirth%27s_law

ithrow 4y ago

Genuine question, why developer productivity was higher in node?

SillyUsername 4y ago

Node is much simpler to work with, and if you're running one shot, short serverless ops (i.e. not batch), faster to start (no JVM cold start) and cheaper to run (less RAM) than Java. If they're really concerned about performance they'd not go wrong by using Deno which often has at least double the performance of Node https://medium.com/deno-the-complete-reference/node-js-vs-deno-vs-bun-server-side-rendering-performance-comparison-f80a5abc766f https://medium.com/deno-the-complete-reference/node-js-vs-de... Deno for a lot of operations is actually comparable to Java level performance: https://programming-language-benchmarks.vercel.app/java-vs-typescript https://programming-language-benchmarks.vercel.app/java-vs-t...

fidgewidge 4y ago
Of course there is cold start. Both Node and Deno use JIT compilation just like regular Java, which means they warm up. JS code will use more RAM than Java for equivalent constructs, not less. You may be fooled though, by the way that the JVM by default will use free RAM rather than burn energy/CPU collecting garbage when it doesn't need to. So it will look like your app is using a lot of RAM but in reality the JVM will give it up when asked.
- SillyUsername 4y ago
  My experience of paying for cloud services does not back that up. Java AWS Lambdas are typically 2-3x heavier in memory usage than a TS/JS equivalent, and the benefit of that warmup is negated if the Lambda shuts down due to idle time. "Give it up when asked" !== less streamlined, it means expanding heap is required for normal operation. Too little heap, it buckles, GC is almost constant, and performance goes out of the window.
  - fidgewidge 4y ago
    That's inherent to any GC algorithm. More CPU time = less RAM usage because garbage is collected more aggressively. I don't understand why you think that JS, a JIT compiled GC'd language, doesn't warm up and doesn't have to trade off GC time vs memory.

fidgewidge 4y ago

> Node is slower but since it's single threaded they load balance a bunch of servers and in practice it's just as fast when considering the developer productivity This sentence doesn't make any sense. It can't be both slower and just as fast, developer productivity is a totally different concept to performance. And being single threaded just means you have to spend more RAM to saturate your CPUs (threads are cheaper than processes), nothing stops you running many single threaded JVMs and load balancing across them, it's just inefficient.

krzyk 4y ago

> just as fast when considering the developer productivity I wouldn't use Javascript and developer productivity in the same sentence.