| > Servers are where the problem is. The GIL makes python functionally single-threaded, which is a bummer for your server at any kind of scale. Right, agreed. I can imagine some of the frustration you might experience using CPython for high throughput systems: kind of like NodeJS without the benefits of a standard library written with async/non-blocking I/O in mind. A bit curious about a few things you mention here, though: > Or that a python process never really releases memory back to the system, just within itself, so the process slowly grows over the course of a few weeks. I'm not sure this is true in general, is it? Can you elaborate? It's been a while since I've dug around in Python innards, but if Py_DECREF(x) leads to a refcount of zero IIRC free(x) is ultimately called -- albeit in an indirect manner via a layer or six of tp_dealloc calls and tp_free. :) I suppose calling free(x) may only return the memory associated with x to (g)libc's free list and not necessarily back to the OS [0]. No different to C/C++ in that regard, I guess. > I came to the conclusion that python is unsuitable for servers, but until Go came out, there wasn't a realistic alternative, since C++ and Java are too heavyweight, and Ruby suffers from similar problems (don't know about a GIL). "Too heavyweight" in that they're relatively difficult to write in comparison? Maybe true of Java-the-language, but the JVM itself is an absolute workhorse when it comes to high performance. Plenty of languages to choose from there, typically without a GIL. Jython, for example, has no GIL [1]. And yep, Ruby/MRI has a GIL (but JRuby does not). [0] https://www.gnu.org/software/libc/manual/html_node/Freeing-a...
[1] https://stackoverflow.com/questions/1120354/does-jython-have... |