I would not be surprised that Rust be faster than Python, but looking at the code of his Benchmarks, I'm not sure that it really means anything.

For example, the "light" test will do calls to "dynamodb". Maybe you benchmark python, or you benchmark the aws sdk implementation with different versions of python, or just you benchmark average dynamodb latencies at different times of the day, ...

And, at least for Python, his cpu and memory test code looks like to be especially specific. For example, if you use "sha256" or any other hashlib, you will not really benchmark python but the C implementation of the hashlib, that might depend on the crypto or gcc libraries or optimization that was used by AWS to build the python binaries.

Sure. Who is to say where the bottleneck is, but if an application is going to use all those same libraries and runtimes, it’s not an unrealistic test. Obviously, with all benchmarking, the most accurate benchmark is your own application, but this seems pretty reasonable as a generic first cut.

I think the 'light' workload is the most realistic - most people use lambda as a stateless CRUD backend/REST endpoint, I don't think doing heavy number crunching is that idiomatic inside a lambda.

And for that use case, Python seems almost as good as Rust, which is surprising to me, as is the fact that Node runs so slow - I have a ton of Node-based lambdas in prod, and while they're no speed demons, I'm quite surprised how bad it is compared to even interpreted things like Python.

AWS should really look into this and fix it, or at least tell us why it's so slow.

Yeah, having a native binary be only 2x faster than CPython, or CPython showing 4x (!!) advantage vs. V8 seems really suspicious. This benchmark suite is probably good for looking at CPU architecture deltas on identical source code (which seems to be what it was good for), but trying to intuit language/runtime behavior from it seems very dangerous.