Don't forget startup and distribution time. It's not terribly hard to have a scratch rust container which is about as slim and secure as you can get. That container will startup pretty much instantaneously even if it's cold.

You are looking at ~5mb container vs 200+mb if you did a jvm based container.

It's probably overkill for most applications and companies, but it's something to keep in mind if you need fast scaling for cheap.

For webdev Go scratch containers are really nice and quick to develop. Of course the language could use better error checking but that's about it. It really does that job well. Fast, secure (GC and yes you can ignore errors the same way you can unwrap() the world).

Rust will be much lighter than any JVM app, but a fairly complex JVM app can be compiled to a self-contained JVM distribution on around 25MB these days... you use jlink to compile the app and parts of the JVM that you actually use.

Not to mention you can use GraalVM native-image to compile to a binary directly, in which case it'll be even smaller.

Startup time is a great feature for all sorts of FaaS environments as well. Especially when combined with Rust's generally low resource use.

Go has these same properties

> This is true in some senses, but also, response latency isn't the only thing a web application does or is evaluated by. Many applications have, for example, background jobs, that do arbitrarily complex processing outside of the request/response cycle.

Yeah, for sure -- I deal with a web app that does complex, time-consuming analytics in data pipelines with Python, and Rust could help a lot with improving some of the complex calculations. But again, that's more using Rust as a C++ replacement rather than looking at replacing, say, the Python-Flask frontend that serves up the results of those analytics.

> Additionally, people who write web services in Rust talk about decreased memory usage, consistent memory usage, and lower CPU usage. In a cloud context, that can translate directly to revenue saved, by spending less. If that tradeoff is right for you depends on a variety of things, of course. "speed" isn't the only relevant metric that you may want to optimize for.

It'd definitely reduce costs, but yeah, be sure to get a full picture here from a business perspective. Engineers love to optimize AWS costs, but it isn't appropriate in a lot of situations. In my case, I'm paying a nontrivial 5-figure monthly AWS bill, but if my company's AWS costs went to $0/month... it wouldn't move our death date, and it wouldn't change our valuation. This is especially true if there were any loss in developer productivity/feature releases. I would gladly double my AWS bill if I could get features out even 20% faster, though that's not how it works, obviously.