41–50 of 259 posts
Earlier quoted context omitted.
Managing processes is more annoying than threads, though. Incl. data passing and so forth.
The "ray" library makes running python code on multi core and clusters very easy.
More than seeing it in main, I'm happy for the "python thread slow" meme officially going away now.
I wish I had your optimism. Thoughtless bandwagon-y "criticism" is extraordinarily persistent.
While the title is correct, it is a bit misleading, because disabling the GIL breaks the asyncio tests. It's like saying the engine can be removed from my car. Sure, it can, but the car won't work.
Earlier quoted context omitted.
multiprocessing only works fine when you're working on problems that don't require 10+ GB of memory per process . Once you have significant memory usage, you really need to find a way to share that memory across multiple CPU cores. For non-trivial data structures partly implemented in C++ (as optimization, because pure python would be too slow), that means messing with allocators and shared memory. Such GIL-workaroun…
And I guess what I don't understand is why people choose Python for these use cases. I am not in the "Rustify" everything camp, but Go + C, Java + JNI, Rust, and C++ all seem like more suitable solutions.
I've been programming in Python for over 6 years now and every week I learn something new. But recently I've been thinking about moving to a more capable language with proper concurrency for backend API requests (FastAPI sucked). I also want types, so Elixir is not in the picture. I dabbled in Rust a bit. Although I was able to get the hang of things and build a CLI tool pretty quickly, I'm worried I'll have to deal…
Python supports types! https://www.mypy-lang.org/
Earlier quoted context omitted.
multiprocessing only works fine when you're working on problems that don't require 10+ GB of memory per process . Once you have significant memory usage, you really need to find a way to share that memory across multiple CPU cores. For non-trivial data structures partly implemented in C++ (as optimization, because pure python would be too slow), that means messing with allocators and shared memory. Such GIL-workaroun…
And I guess what I don't understand is why people choose Python for these use cases. I am not in the "Rustify" everything camp, but Go + C, Java + JNI, Rust, and C++ all seem like more suitable solutions.
I think Python is a terrible language that exemplifies the maxim "worse is better".
I was a bit disheartened when the Unladen Swallow project [1] fizzled out. Great to see Python back on the core optimization track.