News for hackers. Stuff that matters.
Re:A viable solution for Python concurrency by SoylentOrange on Friday October 15, 2021 @10:16PM (#28885031)
> My personal view is that the world has largely moved on from dynamically typed languages for anything non-trivial or that isn't essentially plumbing. For good reason. Of course people will bring up Javascript but it has a captive market as being the only thing that'll universally run code in a browser and the likes of TypeScript can ease that burden anyway.

This is not correct. There is a lot of data analysis code in the research and scientific community written in python. A lot of PyCon attendees and speakers come from these communities. Oftentimes, it’s not easy to write code to perform a task entirely in numpy, and then you incur massive slowdowns (often 20-100x). This is a common and contemporary problem in the python ecosystem.

GVR initially didn’t think that python needed to be faster either, but recently changed his mind. You can find a presentation on his motivations here: https://github.com/faster-cpython/ideas/blob/main/FasterCPyt...

Sam Gross comes out of that community so he’s familiar with the motivations for making raw python faster.

Re:A viable solution for Python concurrency by qstwall on Saturday October 16, 2021 @03:47AM (#28886250)
It will still be slow if the threaded code is in pure Python.
Re:A viable solution for Python concurrency by SoylentOrange on Saturday October 16, 2021 @09:51AM (#28887883)
> When pointed to the "ccbench" benchmark, Gross reported speedups of 18-20x when running with 20 threads.

I would be very happy with that, together with a 10% speed increase in single-threaded performance that they said would come as a result of these changes.