Perhaps it was my wording that caused this confusion, for which I am sorry, but I never meant to compare "pure" Python with C. The point I am trying to make is that, Python with C extensions can be as considerably performant as C code for network or memory bound tasks.
: It's of course controversial whether 60% throughput is considerable or not.
But personally, I don't see how the usage of hiredis is so much different from literally taking a part of Redis itself and embedding it in Python. As a thought experiment, if I did take Redis's parsing code and embed it in Python, would it still be fair?
I'm not really convinced that a pure Python implementation of the Redis Serialization Protocol would actually be meaningfully slower than the Python bindings to hiredis, so this whole thing may be a bit moot.
I think your project is cool. Perhaps some changes to the README to explain exactly what your benchmarks are meant to show about Python itself would help the criticism.
I agree. I'll edit when I have some time this week. =)
> Unfortunately many programmers, due to their lack of experience, of some knowledge of computer architecture(s), or of an in-depth understanding of the task they are given
Where you fail to see that C libs being linked into python code is the same as python code performance
It's strongly typed and mypy adds static typing support too (so you end up with a strong gradually typed language). Would you consider it insufficient?
Sure, it's strongly typed, but I think that's irrelevant, at least if my understanding of the term 'type safe' is correct. From Wikipedia:
>In computer science, type safety is the extent to which a programming language discourages or prevents type errors.
The thing is, a Python program that causes a type error is valid, even if it crashes. TypeError is strictly a runtime error. To me, that is the epitome of not having type safety.
Of course pretty much everything is runtime in Python, by virtue of it being a script language. So you really would need a type checking stage, like TypeScript. But...
>mypy adds static typing support too
In my opinion, MyPy is not sufficient to represent common usages of Python's type system. Even with the recent addition of structural typing, many Python programs just do things that are not easily typed. An example would be, in Django, many things in the core directly patch the Request object, and there's really not a terribly sane way to represent this in a reasonable type system. I feel Python encourages all kinds of type craziness, with metaclasses, 'file-like' objects, etc.
Not strictly related, but there are also other type checkers, too: At Google, we've got pytype (https://github.com/google/pytype) and Facebook has pyre-check (https://github.com/facebook/pyre-check). I've tried neither myself.
I'd like to see the same thing in a few different languages, just for fun - perhaps a Perl or Rust redis, for example.
This takes advantage of probably the two highest performing aspects of Python: raw dict and async (especially under uvloop).
If your app does mostly those things, then yes, Python is a good choice. It doesn’t say much about anything else.
Since we're sharing Redis clones, here's my multithreaded one: https://github.com/JohnSully/KeyDB
From my limited understanding of Python, it compiles into bytecode that is fed into a virtual machine doesn't it? How can that ever be just as fast as C? Unless the C programmer does a really bad job?
You might want to check the r/Python thread as well: https://www.reddit.com/r/Python/comments/awav6k/pydis_a_redi...
When I have some time, I'd love to port those two to pypy and see how it performs (but porting uvloop would be task on its own!)
That sounds like the definition of confirmation bias.
How is that substantiated?