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.
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 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.
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.
> 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
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.
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.
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.
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.
46 comments
[ 4.1 ms ] story [ 95.5 ms ] threadThe 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.
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
https://github.com/mitsuhiko/minijinja
A lot of web development sees no real scale.
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
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/
>Written in Rust, btw xD
They'll tell you.
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).
Well there's one way to have both: just write all your logic in a language that compiles to native.
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
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 :)
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.
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.
At the end of the day, it's still the case that the interpreter is written in an different language, though.
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.
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.
[1]: https://jcristharif.com/msgspec/benchmarks.html
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
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
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
Robyn - With Every Heartbeat (Live Nobel Peace Prize 2008)
https://www.youtube.com/watch?v=0oIuXDX8EcA&t=4s