3 ms·

I am not an expert in python but I feel that the JS model where everything is on the event loop and there is no actual threads seem better for a dynamic languag

I am not an expert in python but I feel that the JS model where everything is on the event loop and there is no actual threads seem better for a dynamic language. A lot of parallelization can be achieved with web-workers, but of course at the cost of relying on copying memory between workers (ie no shared memory). There have been some proposals to add full shared memory constructs (SharedArrayBuffer) and synchronization (Atomics) mechanisms, but they are special constructs and don't work with normal javascript objects. Quite limited but provide full parallelism for things that usually need it (buffers). One thing people often forget is that thread-safe data structures are usually a lot slower than single-threaded one, everything in JS is single threaded and in the event loop, but if you really need it there are some scape hatches. I don't know, this just feels better and simpler? If you really need to you can go down to a lower level language for full memory sharing data structures.

logicchains 3y ago
>I am not an expert in python but I feel that the JS model where everything is on the event loop and there is no actual threads seem better for a dynamic language Python has become essentially the primary language for scientific computing and deep learning, and for this the JavaScript approach is absolutely inadequate. Real shared memory parallelism is needed to avoid the unnecessary copying that the subprocess approach entails. >I don't know, this just feels better and simpler? If you really need to you can go down to a lower level language for full memory sharing data structures A low level language is already used in Numpy, PyTorch etc., but that's not enough; the Python glue code becomes unnecessarily painful when using multiprocessing, pain that would go away with proper threads.
- DanielHB 3y ago
  If you disregard the existing libraries and think purely about the concepts and powers of the languages, the JS model seems better to me. You can avoid memory copying between workers by using SharedArrayBuffer
danielrhodes 3y ago
I don't think people use Python because it's fast. It gained momentum because it has good libraries for data science and ML. Other languages, including JS, are far faster at this point. However, the reason to use JS in particular is because when you have a lot of I/O blocking calls (DB calls, web requests) it really is a lot faster. But if you do anything with numbers, JS is the wrong language - it's so limited here that it's almost laughable. Same with dates. That makes it a very bad choice for data science.
- ahartmetz 3y ago
  > It gained momentum because it has good libraries for data science and ML That's pretty far from a root cause though. I'd say it has these because - get this - it's actually a quite nice language to work with, so some people prefer it, and other people can handle it, unlike more difficult languages. In particular, Python is fairly small / minimalist (though the cruft is accumulating...), straightforward and powerful. That is somehow barely mentioned among all the performance complaints. Me, usually writing C++, I like it for writing various little helper tools. No deep notebook tensors are involved in that work. It's mostly file and string processing, in one case also a GUI and Excel (unfortunately) tables.
abdulhaq 3y ago
python already has asyncio

logicchains 3y ago

>I am not an expert in python but I feel that the JS model where everything is on the event loop and there is no actual threads seem better for a dynamic language Python has become essentially the primary language for scientific computing and deep learning, and for this the JavaScript approach is absolutely inadequate. Real shared memory parallelism is needed to avoid the unnecessary copying that the subprocess approach entails. >I don't know, this just feels better and simpler? If you really need to you can go down to a lower level language for full memory sharing data structures A low level language is already used in Numpy, PyTorch etc., but that's not enough; the Python glue code becomes unnecessarily painful when using multiprocessing, pain that would go away with proper threads.

DanielHB 3y ago
If you disregard the existing libraries and think purely about the concepts and powers of the languages, the JS model seems better to me. You can avoid memory copying between workers by using SharedArrayBuffer

danielrhodes 3y ago

I don't think people use Python because it's fast. It gained momentum because it has good libraries for data science and ML. Other languages, including JS, are far faster at this point. However, the reason to use JS in particular is because when you have a lot of I/O blocking calls (DB calls, web requests) it really is a lot faster. But if you do anything with numbers, JS is the wrong language - it's so limited here that it's almost laughable. Same with dates. That makes it a very bad choice for data science.

ahartmetz 3y ago
> It gained momentum because it has good libraries for data science and ML That's pretty far from a root cause though. I'd say it has these because - get this - it's actually a quite nice language to work with, so some people prefer it, and other people can handle it, unlike more difficult languages. In particular, Python is fairly small / minimalist (though the cruft is accumulating...), straightforward and powerful. That is somehow barely mentioned among all the performance complaints. Me, usually writing C++, I like it for writing various little helper tools. No deep notebook tensors are involved in that work. It's mostly file and string processing, in one case also a GUI and Excel (unfortunately) tables.

abdulhaq 3y ago

python already has asyncio