4 ms·
Well, there are a bunch of reasons of maintaining the "charade". Firstly, faster languages don't have the ergonomics. Secondly, there's a tonne of Python code
by talideon 4y ago
Well, there are a bunch of reasons of maintaining the "charade".
Firstly, faster languages don't have the ergonomics.
Secondly, there's a tonne of Python code out there already that isn't going away any time soon, and any effort to make the runtime faster benefits all that code.
Thirdly, there's little reason Python can't be as fast as the likes of JavaScript beyond the issues imposed by the C extension API. The reality is that not a lot of effort has historically been put into making the CPython runtime particularly fast. It's only recently that anyone's put any concerted effort into it.
- pjmlp 4y agoThe community could have gathered around PyPy, but it seems a lost battle by now.
- talideon 4y agoThat's a whole other issue. PyPy and CPython have conflicting aims, which is partly why it never replaced CPython as the defacto default Python runtime. Also, PyPy is much slower for stuff that's only going to run for a short time. Still, many of the lessons learned in PyPy can be used to improve CPython performance.
- pjmlp 4y agoThey only have conflicting aims due to politics, otherwise a way to work towards a common goal would have happened. CPython devs will only accept proper JIT when the language really starts getting a betting from the likes of Julia, Chapel, Go, JVM and .NET bindings to the same underylying C/C++/Fortran libs.