I feel like Python should be much faster already. With all the big companies using Python and it's huge popularity I would have expected that a lot of money, work and research would be put into making Python faster and better.
There are other languages you can use to make stuff go fast. Python isn't for making stuff go fast. Its for rapid dev, and that advantage matters way more when you already are going to be slow due to waiting for network response
A well organized python codebase really is faster to work on than other languages. If your dev work is slowing down as the codebase grows, that's a sign you're accruing tech debt by not keeping up with organizing it.
But on a slightly less edgy note: java doesn't have a fast REPL loop, near anywhere near the amount of libraries available for it as Python does, and requires tuning to actually make it performant. Its by far not the same amount of time to develop. It doesn't have things like jupyter notebooks for prototyping, doesn't have an easy to use interpreter, doesn't have ability to inject code during debug sessions, and doesn't have easy system integration (i.e with a module, you can install it in editable more, you can have an executable you can run from command line, e.t.c), and doesn't have things like dynamic import (where you can dynamically reload modules as the program is running, can't (easily) import inside function statements, and so on)
>Sure, there's multiprocessing, but historically no multi-threading
Functionally, when the cpu switches context the main thing that matters is the stack frame. This happens in both threading or running multiprocessing. The only difference is between the two is a) data access and b) initial startup time.
a is solved by unix pipes,which is already a part of multiprocessing in python, which are plenty fast for anything you wanna do, and b is solved by spinning up the processes ahead of time in worker pools, which is already part of multiprocessing in python.
The key distinction between multiprocessing and multithreading is that in multithreading all the threads of a process share the same memory. Are you saying that Python uses pipes for providing shared access to memory across processes? It looks like there is: multiprocessing.shared_memory, but this all seems more complicated than it is in other languages. Perhaps it's not?
I will 100% give you that Python has more libraries, but that's the only real advantage I was able to glean.
The way python multiprocessing is set up is that it acts like a thread - when you launch a function, it copies the memory of the current process into the new one. You pay the startup overhead, so instead you launch worker processes ahead of time, and transport data to them over unix pipes. Pretty much almost as fast as threading.
>You appear to have been traumatized by Java
Not really, I just have standards. Java is just a poorly designed language with poor community support. Look at the amount of code it takes to send an HTTP request in Java, versus Python.
And if that memory is large enough then you OOM, so you would have to manage shared memory separately to prevent it from being copied into each process. It's not impossible, just complicated for some use-cases where using threads is a preferable paradigm.
> Look at the amount of code it takes to send an HTTP request in Java, versus Python
This is kind of my point.... (Java)
var client = HttpClient.newHttpClient();
var request = HttpRequest.newBuilder().uri(URI.create("https://api.example.com/data")).build();
var response = client.send(request, HttpResponse.BodyHandlers.ofString());
response = requests.get('https://api.example.com/data')
OOM is not an issue these days lol. Memory is dirt cheap, and the amount of memory that gets copied is miniscule per process.
There is still also the design of the application, just like with threading.
>(Java)
Forgetting the main class there, and also any additional headers that you need to send.
This is what is not always true. Sometimes you have a processing context that is GB in size, in which case scaling via multiple processes is not as simple as if you had access to threads that share that context by design. You will run out of memory really quickly if you spin up enough processes, and even if you have unlimited RAM you could have used 1/nth the memory. If you implement some method of sharing memory between processes to consume less overall, it will still come at the expense of speed and complexity.
> Forgetting the main class there
In Java 21+ you can omit it:
void main() {
System.out.println("Hello, World!");
}
[Multithreading] Cons:
A single thread crash can bring down the entire process.
Not ideal for CPU-bound tasks on a single core due to limitations like Python's Global Interpreter Lock (GIL)