Hacker News Reader

Comment by t8sr | Hacker News Reader

Others point out that calling it a Python framework might be disingenuous, but only if your goal is to compare programming languages.

If you're a web developer, trying to pick a framework for websockets, you probably don't care that the Python framework is a libuv wrapper, while to Go framework is native.

So well done, I guess? I am really happy to see library authors taking performance seriously!

EDIT: This is assuming the benchmark is actually fair. I haven't looked at it, but it's not uncommon for benchmarks to be comparing apples and oranges.

View on HN

Python framework because is an framework for python, like most performance focused frameworks for python, this uses a lot of native code. uvicorn uses uvloop that is an wrapper for libuv.

Web developer dont care if the framework is written in native or it is an wrapper, developers just want something that works in a nice way :D

The benchmarks are in https://github.com/TechEmpower/FrameworkBenchmarks

EDIT: some preliminary results https://www.techempower.com/benchmarks/#section=test&runid=1...

Go developers might though. A go library that requires native is a pretty big reason to avoid. Similarly a headline “c framework that uses libuv is faster than go fiber” wouldn’t cause an eye blink.

So the concern is the title you used to get to the front page not the actual implementation.

I see, but like i said any performance focused Python framework are native (C/C++), so i will never be able to compare any Python framework with Golang framework ever.

The title seems accurate and appropriate to me. If I were selecting a framework for performance I might chose this framework, which I would use through Python, rather than a Go framework that I would program in Go. It's a framework, you use it with Python, and the performance is good (apparently, I didn't check).

> So well done, I guess? I am really happy to see library authors taking performance seriously!

> EDIT: This is assuming the benchmark is actually fair. I haven't looked at it, but it's not uncommon for benchmarks to be comparing apples and oranges.

What is the point of this negativity? Why are you implying that the benchmarks might not be fair because you "haven't looked at it"?

I actually read their comment as positive, with a small caveat about the benchmarks. It's pretty common to see benchmarks here, where the load is very artificial and hence doesn't translate to real world usage, for instance. So I think it's an okay disclaimer.

> EDIT: This is assuming the benchmark is actually fair. I haven't looked at it, but it's not uncommon for benchmarks to be comparing apples and oranges.

well, a real world test would be both servers parsing 100kb json payload in each message

that would be an JSON benchmark not right? raw throughput is more useful to test WebServers, but JSON performance is also important, but i think is another benchmark. PyPy do very well in JSON too take a look https://www.techempower.com/benchmarks/#section=test&runid=1...

Reply on news.ycombinator.com