[hugelgupf]

They are effectively measuring how fast AWS infrastructure can reach whatever it needs (VM?) for each language.

But these are not even cold start times. I'm assuming after the first request this is using the same VM (/backend job, whatever) to reply, so now it just depends on latency to get to that VM. (I'm assuming the runtimes' ability to return "200 OK" is similar and the latency of that is negligible compared to AWS infra that is involved.) Not completely meaningless, but not super useful either, esp without any details while making those bold statements. This is not "Go is equal to Java". This is "AWS Lambda infrastructure for Go is comparable to AWS infra for Java". Article is unclear on that.

Maybe this tells us AWS lambda backend infra is way different for .NET Core than Go and Java? ¯\_(ツ)_/¯

[petethepig]

> This is "AWS Lambda infrastructure for Go is comparable to AWS infra for Java"

I wouldn't even go that far. They are not measuring anything that any real-world application would do. Heck, it's not even a todo app, it's just a "200 OK hello".

It's more like "AWS lambda function invocation overhead for Go is comparable to AWS lambda function invocation overhead for Java".

[weego]

Sure but if you start adding in language specific Web frameworks / json handling / db work you're no longer testing AWS.

I agree there's questionable value here but at least it's bring constrained to as few variables as possible.

[lsaferite]

Benchmarking the lambda-add latency is something that is useful as long as it's called out as such a benchmark.