4 ms·
If you actually read the article, it proposes ways to deal with the issue and discusses some tradeoffs. Erlang may have different tradeoffs, the ecosystem may
by louwrentius 4y ago
If you actually read the article, it proposes ways to deal with the issue and discusses some tradeoffs.
Erlang may have different tradeoffs, the ecosystem may be smaller, less libraries available for important tasks, who knows.
The religion of the one true language has to die, it all depends on the circumstances which language is the best fit.
- crabbone 4y agoI 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.