4 ms·
I actually read the article. And it's a thousand and first such article about the same problem. And the "solution" the article suggests is a non-solution. It
by crabbone 4y ago
I actually read the article. And it's a thousand and first such article about the same problem. And the "solution" the article suggests is a non-solution. It's a ridiculous clutch. But, people who are used to Python are accustomed to living with clutches and patches where none are really necessary.
Python's multiprocessing doesn't hold a candle to Erlang's processes. It's a subprocess.Popen('python') with extra steps and lots of pitfalls. Erlang went through several iterations of process schedulers, several iterations of interfacing with foreign code from Erlang processes... Python developers don't even know yet they will have to solve these problems once multiprocessing becomes more mature (but it never will, so, who cares?)
- louwrentius 4y agoYes, who cares. You apparently. But mostly from an identity politics perspective stomping on Python developers. Yet you know nothing about the specific particular context in which people would use Python Multiprocessing. And I bet that although not ideal from a purity standpoint PM is likely to be “good enough” for a lot of use-cases. You seem so bitter and feel superior about those Python developers yet, here you are complaining like a bitter old person adding nothing of value to the discussion. I really feel sorry for you that you are like that.