3 ms·
Python: absolutely necessary due to the amount of processes and various deployments to run an application once it grows. Java: never felt the need even on quit
by matsemann 1mo ago
Python: absolutely necessary due to the amount of processes and various deployments to run an application once it grows.
Java: never felt the need even on quite big apps. As it's much easier to share a connection pool locally, it's not as many single connections across the whole app.
- tyre 1mo agoYour 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.
- atomicnumber3 1mo agoThey 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.
- tyre 1mo ago> 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.
- ketozhang 1mo agoYou've misunderstood the GIL and Python threads. For I/O, you can add threads and share the same connection object. Like any other languages, you are responsible for making it thread-safe. There's also async. Many Python web apps spawn a thread per worker in your web server, not processes. Look into ASGI vs WSGI.
- pocksuppet 1mo agoLanguages 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.
- mike_hearn 1mo agoMulti-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.
- pocksuppet 1mo agoThe hardware doesn't know anything about processes. The most efficient model, hardware-wise, is to disable virtual memory and never do a context switch, but we don't see anyone programming like that, except for the crazy SDN folks who are doing software packet forwarding at hundred-gigabit rates.
- mike_hearn 1mo agoWell, a server running a single process is fairly close to that. Switching to kernel mode doesn't require a full context switch and nor does switching between threads.
- tredre3 1mo ago> PHP runs a separate logical process on every request which can't share resources with any other request. PHP allows persistent connections to postgres that will be reused by subsequent requests. But of course the connection isn't shared by concurrent requests (unless you use Swoole), so it doesn't solve the process-per-connection on postgres' side, it merely saves some overhead.
- ketozhang 1mo agoIt's more so horizontal vs vertical scaling rather than languages. You aren't running large scale xact/s on a single node.