3 ms·
> I do not think python should try to be concurrent Fair. > or any more performant than it already is. Well, you can certainly argue that you’d prefer that t
by wokwokwok 5y ago
> I do not think python should try to be concurrent
Fair.
> or any more performant than it already is.
Well, you can certainly argue that you’d prefer that the effort devoted to performance could be better spent elsewhere, but it seems a little down to say you don’t think it should be faster.
Let’s not beat around the bush here: pure python is orders of magnitude slower than other similar tier languages, eg. javascript.
That’s because it’s never been a priority.
It also keeps getting new features.
You can’t keep adding new features to anything without it getting slower bloating and becoming sluggish unless you devote effort to keeping things fast.
So, I certainly have no problems with people working on making it faster.
That’s awesome.
The goal isn’t “pure python only, no more c!”
It’s just: stop the pure python code being such a major bottleneck.
- slaymaker1907 5y agoThere are a lot of advantages though if you can get the interpreter fast enough to write more the standard library in Python instead of C. Racket moved to the Chez Scheme VM recently because it is much easier to maintain Racket/Scheme code than it is to maintain C. At my job, there are way more code scanning and audit requirements for any serialization code written in C/C++. While serialization code is always somewhat risky, at least you don't need to worry about buffer overflows in your parser if it's written in Python.