I thought Rust was faster for basically every metric?
The entire advantage of Python is supposed to be ease of development, in exchange for slower code execution. It is especially bad in terms of multiprocessing, which Rust is great at.
As I severely lack expertise on back-end development I asked for clarification to the forbidden oracle (AI) but it also told me that Rust is faster. I am not sure whether you feel like debunking an AI comment but if this is false I would love to hear why because from my current understanding Rust is always faster (for back-end development).
AI response
That statement is technically false, but it contains a grain of practical truth that often confuses people.
Here is the breakdown of why that statement is misleading and where the misunderstanding comes from.
The Verdict: False
Rust is almost invariably faster than Python, even in IO-bound tasks.
If you have a web server handling 10,000 concurrent connections that are all waiting on a database (pure IO-bound), the Rust server will use significantly less RAM and CPU to manage those “waiting” connections than the Python server.
Why the statement is wrong (The Technical Reality)
The argument assumes that “IO-bound” means the CPU does zero work. That isn’t true. Even in an IO-heavy application, the application server must do the following:
Event Loop Management
The server has to track which connections are waiting and which are ready to resume.
Rust’s async runtimes (like Tokio) are incredibly optimized and have near-zero runtime overhead.
Python’s asyncio loop has significant overhead because it is still running interpreted Python code to manage the tasks.
Serialization/Deserialization
When the database replies, the server receives raw bytes. It must turn those bytes into objects (JSON parsing, ORM model instantiation). This is CPU-bound work.
Rust does this near-instantly.
Python is notoriously slow at object instantiation.
The GIL (Global Interpreter Lock)
Even if your code is async, Python can only execute one bytecode instruction at a time per process.
If 100 requests come back from the DB at the exact same millisecond, Python has to process them one by one.
Rust can process them in parallel across all CPU cores.
Where the statement is “Practically” True (The Grain of Truth)
The person making that statement is likely conflating “faster” with “indistinguishable to a human.”
If a database query takes 100ms:
Rust overhead: 0.1ms → total response ≈ 100.1ms
Python overhead: 5.0ms → total response ≈ 105.0ms
To the human user, 100.1ms and 105ms feel exactly the same.
In this specific context, you could argue that Python is “just as fast” as Rust because the bottleneck is the database, not the language. But it is incorrect to say Python is faster.
The “Fediverse” Exception (Why it matters for PieFed)
The statement “web servers are IO-bound” is often true for something like a simple blog.
It is less true for the Fediverse.
ActivityPub (the protocol PieFed and Lemmy use) involves two things that are heavily CPU-bound, not IO-bound:
JSON Parsing
Fediverse servers throw massive JSON blobs at each other constantly.
Python is slow at parsing JSON compared to Rust.
Cryptography (RSA Signatures)
Every time a server sends a message to another server, it must cryptographically sign it (HTTP Signatures). Every time it receives a message, it must verify the signature.
Rust handles crypto operations natively and extremely fast.
Python relies on C-extensions (like cryptography), which are fast, but the overhead of calling back and forth between Python and C for every single request adds up.
Conclusion
The statement is false.
Rust is faster at raw execution.
Rust is faster at handling high concurrency (even IO-bound).
Python is only “faster” in one metric: development velocity – you can write the code faster in Python, but the code itself will not run faster than Rust.
No, python can be incredibly fast for IO when scaled properly.
You generally don’t run a single process or even program for serving websites. There are task queues, callbacks, microservices etc so the bottleneck is almost never the programming language itself but the tooling and Python’s tooling for web is still miles ahead. Thats why big project ship more Django than Rust and all AI training is running on Python not Rust etc.
Don’t get me wrong Rust is a brilliant language but Python can often be better.
Finally you can outsource high performance tasks to Rust or C from within Python rather easily these days.
Python is an interpreted language, which is fundamentally always slower than a compiled language like Rust. However the main performance bottleneck are actually sql queries, and I believe we make a lot more effort to optimize them compared to Piefed.
Not sure what you mean by “advanced caching”. There is some basic caching for data which rarely or never changes, for example most things in /api/v3/site. But other data like post listings change a lot, so caching is not an option and instead its a matter of optimizing the sql queries (using the right indexes, reducing the number of joins, making benchmarks and looking at query plans).
I thought the biggest problem for Python would be the GIL as it cannot share memory between processes and therefore needs to do use a database or other tool to share between them. Though in hindsight most web related services probably use databases to read and write data and this do not work out of shared process memory.
Threading from a single process is just a bad scaling strategy anyway so GIL is rarely an issue so you’re right most big web stuff does indeed use a database/queue/cache layer for orchestrating multiple processes.
it really depends what’s the metric. Most web server stuff is IO-bound not compute-bound so Python can actually be faster than Rust.
I thought Rust was faster for basically every metric?
The entire advantage of Python is supposed to be ease of development, in exchange for slower code execution. It is especially bad in terms of multiprocessing, which Rust is great at.
As I severely lack expertise on back-end development I asked for clarification to the forbidden oracle (AI) but it also told me that Rust is faster. I am not sure whether you feel like debunking an AI comment but if this is false I would love to hear why because from my current understanding Rust is always faster (for back-end development).
AI response
That statement is technically false, but it contains a grain of practical truth that often confuses people.
Here is the breakdown of why that statement is misleading and where the misunderstanding comes from.
The Verdict: False
Rust is almost invariably faster than Python, even in IO-bound tasks.
If you have a web server handling 10,000 concurrent connections that are all waiting on a database (pure IO-bound), the Rust server will use significantly less RAM and CPU to manage those “waiting” connections than the Python server.
Why the statement is wrong (The Technical Reality)
The argument assumes that “IO-bound” means the CPU does zero work. That isn’t true. Even in an IO-heavy application, the application server must do the following:
Event Loop Management
The server has to track which connections are waiting and which are ready to resume.
asyncioloop has significant overhead because it is still running interpreted Python code to manage the tasks.Serialization/Deserialization
When the database replies, the server receives raw bytes. It must turn those bytes into objects (JSON parsing, ORM model instantiation). This is CPU-bound work.
The GIL (Global Interpreter Lock)
Even if your code is async, Python can only execute one bytecode instruction at a time per process.
Where the statement is “Practically” True (The Grain of Truth)
The person making that statement is likely conflating “faster” with “indistinguishable to a human.”
If a database query takes 100ms:
To the human user, 100.1ms and 105ms feel exactly the same.
In this specific context, you could argue that Python is “just as fast” as Rust because the bottleneck is the database, not the language. But it is incorrect to say Python is faster.
The “Fediverse” Exception (Why it matters for PieFed)
The statement “web servers are IO-bound” is often true for something like a simple blog.
It is less true for the Fediverse.
ActivityPub (the protocol PieFed and Lemmy use) involves two things that are heavily CPU-bound, not IO-bound:
JSON Parsing
Fediverse servers throw massive JSON blobs at each other constantly.
Cryptography (RSA Signatures)
Every time a server sends a message to another server, it must cryptographically sign it (HTTP Signatures). Every time it receives a message, it must verify the signature.
cryptography), which are fast, but the overhead of calling back and forth between Python and C for every single request adds up.Conclusion
The statement is false.
No, python can be incredibly fast for IO when scaled properly.
You generally don’t run a single process or even program for serving websites. There are task queues, callbacks, microservices etc so the bottleneck is almost never the programming language itself but the tooling and Python’s tooling for web is still miles ahead. Thats why big project ship more Django than Rust and all AI training is running on Python not Rust etc.
Don’t get me wrong Rust is a brilliant language but Python can often be better.
Finally you can outsource high performance tasks to Rust or C from within Python rather easily these days.
Python is an interpreted language, which is fundamentally always slower than a compiled language like Rust. However the main performance bottleneck are actually sql queries, and I believe we make a lot more effort to optimize them compared to Piefed.
That makes sense to me logically. Are there advanced caching techniques being deployed? I’m really curious about this.
Not sure what you mean by “advanced caching”. There is some basic caching for data which rarely or never changes, for example most things in
/api/v3/site. But other data like post listings change a lot, so caching is not an option and instead its a matter of optimizing the sql queries (using the right indexes, reducing the number of joins, making benchmarks and looking at query plans).Here is an issue on this topic: https://github.com/LemmyNet/lemmy/issues/5555
I thought the biggest problem for Python would be the GIL as it cannot share memory between processes and therefore needs to do use a database or other tool to share between them. Though in hindsight most web related services probably use databases to read and write data and this do not work out of shared process memory.
Threading from a single process is just a bad scaling strategy anyway so GIL is rarely an issue so you’re right most big web stuff does indeed use a database/queue/cache layer for orchestrating multiple processes.