[rualca]

>>You can just write good Python and get almost as fast code as C that will take you 5 times less time to develop.

In this case we're talking about a >2x slowdown.

The service also has fewer features.

You're talking about development time in a context where development time is largely irrelevant, as this is a service that people reuse and pick based on performance, because lower performance means higher costs to scale enough to meet requirements.

[theginger]

He is comparing a version 4 release of a product used by millions, and a POC I suspect of you took a look at early release of redis performance and features would be a lot closer.

[rualca]

OP specifically did a Python Vs C comparison. Your assertions have nothing to do with the claim behind discussed.

Even so, if you really want to discuss specific technical aspects, you should do well to keep in mind Python's notorious and widely known performance problems, such as those due to Python's GIL, and the fact that even in performance-oriented benchmarks Python lags way behind other languages, specially C

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

If it was easy or possible to mitigate Python's notorious performance issues then we would see the results in these synthetic benchmarks. But we don't, no matter how much time has been devoted to them.

Speaking as someone who writes Python for a living, Python aficionados would do well by avoiding misrepresent Python in ways that a) it's easy to verify and refute, b) goes against it's main technical characteristics. Python is awesome to chug out quick and dirty POCs, exploratory code, glue code that ties together performance-critical parts, utilities, and non-performance critical applications. Performance-critical applications is not, nor it ever was, Python's thing. Once we see Python addictions dos trying to claim that their hammer is the best screwdriver around, we start to sell a losing proposition.