Hacker News new | ask | show | jobs
by jamwaffles 2093 days ago
More "mechanical" stuff like typos in payload fields and deserialisation is MUCH safer (and more pleasant with the derives!) due to the benefits of Rust's type system, but broader stuff like authenticating requests and user roles is still up to the user to implement well for a web app to be safe. IMO the language helps a ton here too.

Performance wise, I don't think I need to repeat half the internet here, but I'll just say you'll be blown away by how little RAM a Rust app/container uses for the number of users hitting it. YMMV of course ;)

1 comments

> how little RAM a Rust app/container uses for the number of users hitting it

I thought that's only for syncronous libraries/frameworks? With async it blows out quite a bit. Everyone except rocket has got async functionality now too.

This doesn't seem true. My mental model says that although synchronous may require somewhat fewer resources when there are few connections, async will win as the number of connections increase.

To illustrate this, consider the cost of spawning a new thread. The stack of a thread is usually a few MB, but lets use 1 MB for simplicity. Then 1000 concurrent connections is 1 GB of memory just for stack space.

With async/await, you don't pay a megabyte per connection because async uses perfectly sized stacks that are typically much much smaller than a megabyte.

Of course you can cap the number of connections, but IO speed puts an upper limit on how fast you can serve a connection, which means that the cap limits the number of connections you can serve per second.

Additionally, I doubt that the overhead at a few connections is large. There's a reason people call async/await a zero-cost abstraction, even if using a runtime such as Tokio introduces some amount of cost.

Just going off what I remember from when async started to stabilise, see the top comment on this reddit thread. It may be be fixed by now or simply just allocated memory instead but many were commenting on it at the time.

https://old.reddit.com/r/rust/comments/cych6a/async_performa...

There was a bug regarding the size of async functions growing exponentially in certain cases at some point, but it should have been fixed now.
Probably worth measuring if that was actual memory consumption or just memory reserved by the kernel. Spinning up several threads will reserve memory but it won't be allocated until you actually try to access it.
I didn't measure any significant difference on memory consumption with async vs sync. I didn't even need to measure perf to notice a difference.