> the model cannot scale to real software needs.

And somehow it is still widely used within Google, Facebook, Amazon, Twitter...

Most of those companies are not writing one-thread-per-request servers, they write non-blocking / async IO Java.

Some will do for sure - but it might not even be "most". There is a suprising amount of thread-per-request code out there. And actually it's doing fairly well - even at the scale of the companies you listed if you are using it in the right place. Right place here means don't use it for a frontend proxy which needs to manage 100k keepalive connections.

But for a service which needs to handle 500 concurrent requests at maximum and doesn't have to deal with TLS anymore it will be fine. And there's enough of those services out there.

A lot of the Java code in bigger companies is also written based on older frameworks like earlier versions of Servlet and J2EE. Those programs will also not make any use of async mechnanisms and prefer a simple programming model instead.

This isn't actually a rebuttal of the point.

C/C++ are also used at Google, FB, Amazon, etc. It doesn't mean that it's not a problem.

I'd bet you're alienating well over half the entire field of software engineering with calling Java, C, and C++ "problems".

You're misinterpreting what I said. I talked about the "main problem with Java", and with C/C++. Saying that a tool has a problem doesn't mean it is useless, far from it.

Amusingly, Loom, which will likely appear in the Java 17 time-frame will allow you to use all that blocking code and it automatically transforms it into non-blocking code. Going to make coding high-concurrency applications a lot easier. Check out the few lines of code needed to convert Jetty from blocking to non-blocking:

https://github.com/rodrigovedovato/jetty-loom/blob/master/sr...

I'm very skeptical of this conversion into loom. Jetty bounds the number of concurrent requests it serves based on the size of its thread pool (of course Jetty also uses a few of the threads to run its acceptors and selectors). The implementation provided here, replaces Jetty's fixed sized thread pool with an unbounded thread pool. This is going to lead to some terrible failure states when the service slows down.

The computational resources of a machine is finite no matter what language you use. You got to put limits somewhere.

Can't wait for project Loom:

https://openjdk.java.net/projects/loom

What alternative model would you suggest? Green threads still introduce bugs (race conditions), and fight over resources (DB connections, filesystem, etc.)

This is just silly. What concurrency model doesn't "fight for resources and introduce bugs"?

Threads (and pointers, which you compared them to) are the abstraction at the hardware level - everything else has to be built on top of them in one way or another. Just because you have access to threads (or pointers) doesn't mean you have to make poor architectural decisions. I'd like to draw your attention to Doom Eternal which takes the thread pool model through to its logical conclusion. (https://twitter.com/axelgneiting/status/1241487918046347264) I hope you'll agree that's an example of meeting the needs of real software. (I'm sure it's not the first or only example of that approach, it was just on my mind because it came up recently.)

> the model cannot scale to real software needs

Most of the highest performance server code across many industries in written in Java. So...

I wonder what do you consider could possibly compete with Java in this space?

Akka streams and actor model make it better