upvote
Your high level buckets are languages but the constraints you list are usage patterns.

You can build applications in any language that have many short-lived transactions in single connections or a few huge, blocking one, or anything in between.

The former case is a good one for PGBouncer (it can interleave transactions) and the latter isn’t (it can’t do much about your three minute long BEGIN…COMMIT). Neither has to do with the language.

reply
They addressed this though? I suspect you are unfamiliar with the GIL in python. The reason for a language distinction is because, as OP says: "As it's much easier to share a connection pool locally".

This may change vaguely soon, but right now you typically scale python apps by starting multiple python processes, while for Java you can just add threads. Python processes can't share a thread pool among all of them, while Java can.

reply
> I suspect you are unfamiliar with the GIL in python.

Sadly, I’m deeply familiar. What made Evan Phoenix’s Rubinius work so exciting in ~2012 was getting rid of the GIL and seeing what was “fixed” by parallelism and what was not.

You make a good point. I didn’t read the parent comment that way but you’re right about how you scale python with the GIL vs JVM.

reply
Languages have affordances. At the extreme ends are PHP, and Java or Go. PHP runs a separate logical process on every request which can't share resources with any other request. Almost everyone using Go is writing a long-running server process because that's how the libraries are designed. Almost everyone using Java is writing a long-running process or a module for one, because Java startup times are obscene. Java also has a very convenient synchronization primitive.
reply
Multi-threaded processes are used because that's the most efficient model, hardware wise. Tasks can maximally share resources. It's not to do with library design or startup time.
reply