Comment by ActorNightly

4 days ago

You can run Python processes in parallel for "scaling". Youtube and Uber run python backends. This is cheaper than developer time per hour.

Sure, there's multiprocessing, but historically no multithreading (relatively recently there is the free-threading interpreter). Each of those processes / threads will also execute slowly compared to most other languages. But we agree Python is not performance oriented... I'm just curious why people think it's a good trade-off when I suspect that writing the same code in say, Java, will take roughly the same time, be easier to maintain (compiler assisted refactoring, type safety, etc), and execute faster.

  • I worked on a python codebase for several years that had over two million LoC. The code was well-organized and under constant development by at least ten devs. There were Java components in the larger project that were occasionally touched on, and it was always slower to work with those parts.

    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.

  • After having worked with Java extensively during my time at Amazon, especially during the log4shell bullshit, I can safely say that if you think Java is viable for anything these days, you lack real world experience of how actual good, efficient dev process is one.

    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.

    • You appear to have been traumatized by Java... You can sub in any statically typed, compiled language.

      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.

      5 replies →