Show HN: Robyn – A fast, extensible async Python web server with a Rust runtime | Hacker News Reader

Show HN: Robyn – A fast, extensible async Python web server with a Rust runtime

github.com

103 pointsprollyjethi42 comments

It is a big red flag to me if a project claims "fast", but does not prominently show benchmarks. Previously I have seen projects that claim to be the fastest which are 10x slower than alternative popular projects.

There are two major benefits I can see from making public benchmarks: 1. showing which other projects you are competing with and 2. having a benchmark suite you keep an eye on helps you actually make your project fast.

I would also like to see some benchmarks, especially compared to aiohttp since that is what it appears to replace. I too am skeptical, aiohttp isn't all that fast, but it's execution time is negligible in a typical application. I found aiohttp to be about half the speed of gevent.pywsgi, but it turns out that doesn't matter at all when the vast majority of time is spent executing business logic and serializing responses.

This is funny, because often times as soon as you add benchmarks, the masses will scream that the benchmarks aren't useful because they don't test real world conditions (global network latency, wide ranges of queries with effectively random patterns, etc.). Benchmarks feel a bit like a "damned if you do, damned if you don't" situation. That said, I love me a good benchmark.

There is even a comment on this page saying requests per second isn't everything. So even if you don't benchmark they will still say that benchmarks aren't useful.

Of course I agree that benchmarks can't tell the whole story, but they can demonstrate huge differences in potential performance which can give you a reason to create a realistic benchmark for your use case.

For my own "fast" projects[1] I've taken to providing benchmarks, but adding a big 'ol caveat at the top describing ways in which the benchmark may not reflect reality. Some people really want to see benchmarks! Others are turned off by projects that overreach on performance claims. I'm hopeful that adding context around benchmarks to tamper excitement strikes the right balance.

[1]: https://jcristharif.com/msgspec/benchmarks.html

I found a performance comparison here [0] and these are the same numbers that they present in a talk I found on youtube [1]. The gotcha I see is they haven't mentioned what version of each framework they're running, python runtime, and I don't see the code used for load testing so who knows what it's actually showing. However, being native code is a huge free win for performance so I don't doubt these numbers for a microbenchmark.

I suspect the reason these aren't "front and center" on the github readme is because the project is very early and many of their commits mention performance. Feature wise it seems reasonably mature but the release cycle is quite fast and they've made a few breaking changes. If I were them, I'd wait until I was near 1.0 before putting performance claims in front too.

[0] https://sansyrox.github.io/robyn/#/comparison

[1] https://youtu.be/QWzp6nFQxPQ

I was pretty curious about the project too (am not the author) and did some digging.

The benchmark is here: https://sansyrox.github.io/robyn/#/comparison

I took a brief look into the internals and turns out it wraps actix web (https://github.com/sansyrox/robyn/blob/main/src/server.rs), one of the more dominant web servers on techempower.

tldr: I dont have a good reason to doubt the performance but seems pretty interesting if you want to use actix web without having to go through rust

Hey,

The project is still in early stage and hence I don't show many comparisons.

Here is a benchmark on TechEmpower - https://www.techempower.com/benchmarks/#section=test&runid=4...

I also have a comparison on the docs website: https://sansyrox.github.io/robyn/#/comparison

And my own benchmark code is https://github.com/sansyrox/robyn-comparison-benchmarks

Good bindings between Python and Rust are a win all around.

PyO3 is great. It makes it super straightforward to write Python extensions in Rust.

It's much more pleasant than writing C extensions, that's for sure.

The Rust/Python toolchain and ecosystem are really impressive. They're not something I would have expected to have developed with as much quality as they have.

Can anybody point me to a reputable benchmark comparing this vs e.g Starlette etc?

Or Flask!

My guess is that "fastest" refers to the request-response loop.

I'd be interested in knowing how fast it is once you tack your favourite template rendering engine on top.

It would be nice if there were drop-in support for Tera, the Rust template engine that is inspired by Jinja2:

https://github.com/Keats/tera

Ronacher has ported jinja2 (partially) to Rust

https://github.com/mitsuhiko/minijinja

Who’s still using a python web framework with Template rendering in real scale ?

What would you use is your app is not an SPA written in React? Consider something like a media site, the kind for which Django was initially invented.

> real scale

A lot of web development sees no real scale.

I rarely saw templating to be a bottleneck. Database access, way more often.

Hey, The project is still in early stage and hence I don't show many comparisons.

Here is a benchmark on TechEmpower - https://www.techempower.com/benchmarks/#section=test&runid=4...

I also have a comparison on the docs website: https://sansyrox.github.io/robyn/#/comparison

And my own benchmark code is https://github.com/sansyrox/robyn-comparison-benchmarks

In my imagination this was the inspiration for the name.

Robyn - With Every Heartbeat (Live Nobel Peace Prize 2008)

https://www.youtube.com/watch?v=0oIuXDX8EcA&t=4s

https://www.sanskar.me/posts/robyns_plans_for_2023 was posted last week.

The project logo is gorgeous!

I can’t find what language it’s written in, can someone help out?

Who cares? Someone will rewrite it in Rust soon.

It says in the description:

>Written in Rust, btw xD

How do you know something is written in rust?

They'll tell you.

I’m always kind of sad that the only way to achieve this always seems to be native code.

I think the value of having all your logic in the same language is undervalued (Ruby and Node also seem to often use bindings to something compiled).

> I’m always kind of sad that the only way to achieve this always seems to be native code. I think the value of having all your logic in the same language is undervalued

Well there's one way to have both: just write all your logic in a language that compiles to native.

But, how often you actually mess up with the internals of your web framework?

edit: here I'm biased because even if I used this project and would send a PR to it, I'm okay with doing it on either Python or Rust. But yeah, not every Python programmer can also code in Rust

I’d be surprised if even 5% of python devs has put self written rust in production.

Python probably has one of the higher percentages of monolingual developers (perhaps only JavaScript is higher?)

But the interpreter itself is written in a compiled language anyway. I don’t see why it matters much that frameworks and libraries you use are compiled code also.

But like another sibling said, if you want all in one language, write it all in the compiled language.

I use the Hyper library written in Rust, and write my code in Rust. One language, and a very nice one at that :)

> I don’t see why it matters much that frameworks and libraries you use are compiled code also.

Mostly ability to easily debug every part of your code. If your interpreter has a problem you are out of luck anyway, but there’s probably a reason you are using a scripting instead of compiled language.

I’m a maintainer of the currently most popular Ruby web server (Puma). It’s mostly written in Ruby.

Chris Seaton (RIP) gave a talk at RubyConf this year that talks about rewriting stdlib in Ruby for truffleruby. The difference is now jit seems to be powerful enough to produce good speedups. Recently some core MRI methods have been rewritten in Ruby and I wouldn’t be surprised as yjit becomes faster if more aren’t rewritten.

I agree, just because it can be a barrier for contributions. Contributors who want to debug, bug fix or add features might end up having to be proficient not in just Python, but also whatever extensions are written in.

At the end of the day, it's still the case that the interpreter is written in an different language, though.

I wish I could find the HN comment recently posted which eloquently explained why obsessing over webserver (and by extension, web framework) performance requests-per-second is foolish.

The closest thing I could find is this:

https://news.ycombinator.com/item?id=34002459

The tl;dr is: server requests-per-second is meaningless without realistic loads involving databases and other dependencies. Typically the external factors dominate request processing time.

There might be compelling reasons to spring for Robyn over Flask [0] or FastAPI [1] but RPS shouldn't be one of them.

[0] https://flask.palletsprojects.com/en/

[1] https://fastapi.tiangolo.com/

This one? https://news.ycombinator.com/item?id=34364975

Not sure if this was it, but you rock for trying to piece it together. This is a good perspective in my humble opinion.

If I recall correctly one of the things that slows FastAPI RPS down is pydantic, though there is active development to make a rust-based core for that too which is supposed to be ~10x faster.

Pelydantic is it's whole own separate comprised of adequate kindling for a religious war.

The fastest _ written in Rust != The fastest _

What is with Rust and "Blazing™ Fast"? I know it should be a meme at this point but it's really getting stale and people don't seem to be using it as such.

Reply on news.ycombinator.com