I'm reading some arguments and counter-arguments in this thread, and in my opinion it kinda boils down to what point of view you're having.

If you look at it as a framework that minimises the networking overhead, then fine, it's an interesting piece of software.

If on the other hand you look at it like a "fast" web framework then things start to change and the discussion gets a bit more complicated.

So for example, you look at the source code of the applications being benchmarked (example: https://github.com/cirospaciari/socketify.py/blob/main/bench...) and you immediately see it's simply returning the string "hello world"). Which means that it's almost 100% of the time running in the fast path / best case.

My guess is that as soon as you start doing any kind of computation in the request handler in normal non-super-optimized python (trival example: validating some headers and/or checking some signatures as you would do with jwt tokens for example) then the python-vs-golang gap will start to go back to favour golang.

And then again, it boils down to what you're doing: anything io-intensive might benefit from the unetworking/uwebsocket beneath, anything cpu-intensive will benefit from the golang compiler producing native executable code.

Nice work anyways.