Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

This helped me: Nobody asks a professional violin player to "just" switch to the cello, because the orchestra is missing one. Yes, there are many musicians who are proficient in multiple instruments, and yes, the underlying music theory is the same and maybe even the playing mechanics might be very similar (e.g. within strings or winds).

A few years ago I made a conscious decision that - at least during my remaining professional career - I will not switch to a new programming language anymore. Instead, I intend to keep specializing in Java. I embrace the fact that in 20 years I will be today's (Assembly|Fortran|C|...)-specialist. I do enjoy reading about other language features. I applaud the people at the cutting edge, experimenting with new stuff, and I am glad that Java is slowly incorporation some of those innovations. Every LTS release (2-3 years), I enjoy learning the curated set that Oracle's language architects decided to add.

This decision helped me tremendously with the fear of missing out on the latest and greatest.

Yet another "X faster than Y" where inside X all hot jobs are done by really good-tuned C or C++. Facepalm.

Without real problem-solving (business logic) written in Python, this is only lightweight wrapper on C/C++. When the number of Python code start growing in the hot path, then these blazing-amazing thruput numbers tremendously will be going down.

Even if there isn't literally such a thing as an "interpreted language" there are absolutely design choices made in Python that you wouldn't make if you wanted it to be fast at runtime. To be fair, this is also true of JavaScript, but in Python the choices were literally intentional, as simplicity of CPython and elegance of the language were long valued over performance.

OTOH, interpreting C++ is actually a pain in the ass due to design choices it makes specifically regarding the semantics of translation units. You can see similar pain when trying to say, make a Go REPL: it's just not tuned for this.

It is of course technically possible to compile almost anything ahead-of-time. But, if you effectively wind up having to ship an interpreter or JIT into the resulting binary to run some code anyways, it's almost for naught. Both Python and JavaScript have eval. Python also has several other cases like Pickle where this can be an issue. PyPy being a JIT makes a lot of sense because it wants to be a drop-in replacement, and that makes the most sense for a language with these constraints. Codon can do AOT, but for practical reasons it is not nearly a drop-in replacement for CPython, just like the other Python AOT implementations.

A practical Python AOT is not compatible with loads of things that people associate with Python, like Django. PyPy is compatible with more, but even it is far from a drop-in today, and that is a problem.

> A language is just a set or rules and keywords. Everything you can fit into Backus–Naur form is already a language even if it doesn't have any implementation nor compiler neither interpreter.

This is objectively true. However, in practice, there are a finite number of available toolchains for any given language that exist today, and creating new ones is a non-trivial endeavor, especially production-quality ones. A language is just a set of rules and keywords. However, when people use Python and write Python, they are not merely writing Python to fit into those keywords and rules. They're writing Python to be executed and solve a problem, typically using CPython. Python is a language, but it's also an ecosystem.

In the same token, if something like Codon doesn't even support all of the things you can fit into Backus-Naur form about Python as it is in CPython and PyPy, can it even be called Python in this sterile technical sense?

I'm so happy this is (currently) the top comment and people are starting to realize measuring perf with these well tuned micro-benchmarks is a sham.