3 ms·
I'm curious to why they started this project when there already is low hanging fruit that can speed up Python (e.g. pypy). What makes this better other than to
by thedjinn 10y ago
I'm curious to why they started this project when there already is low hanging fruit that can speed up Python (e.g. pypy). What makes this better other than to satisfy the inner go-fanboy?
- zardeh 10y agoPypy still has a GIL. GIL-free seems to be one of the explicit goals of this project.
- poooogles 10y ago>Pypy still has a GIL. Not strictly true, http://doc.pypy.org/en/latest/stm.html http://doc.pypy.org/en/latest/stm.html. In general for the main project however, this is true.
- zardeh 10y agoPypy still has a gil. Pypy is experimenting with non-GILed versions, and in fact there are people actively working to remove the GIL from pypy. But the same can be said of cpython (the gilectomy), and yet I don't think that you'd say "not strictly true" to "cpython still has a GIL".
- nemith 10y agoGIL still exists in pypy
- alrs 10y agoBecause they want to get off of Python completely, and forever. They're not looking for speed, they're looking to ditch the liability of supporting Python and its ecosystem.
- JPKab 10y agoYeah, they didn't at all say that.
- randomdata 10y agoOf course, that doesn't necessarily mean it is not true. There are many reasons why Google may not want to reveal long-term plans so explicitly. It's clear that existing Python codebases will be maintained for the foreseeable future – there would be no reason to build this otherwise – but this may signify a shift away from Python for new extensions to the project, as this now makes it possible to integrate Go packages with relative ease.
- Sphax 10y agoIt's right there in the post: > To solve this problem, we investigated a number of other Python runtimes. Each had trade-offs and none solved the concurrency problem without introducing other issues.