3 ms·

This is a good example of an absolutely pointless comparison. The author is making some bold statements: > Go performance is comparable to Java > .Net Core 2.

This is a good example of an absolutely pointless comparison. The author is making some bold statements: > Go performance is comparable to Java > .Net Core 2.0 can execute up to 3x faster than Go. > Consistent performance of compiled vs dynamic But what are they measuring? How fast can a lambda function return "200 OK hello"? This is just sad.

hugelgupf 9y ago
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 9y ago
  > 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 9y ago
    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 9y ago
      Benchmarking the lambda-add latency is something that is useful as long as it's called out as such a benchmark.
IloveHN84 9y ago
It's a pity there's no C/C++ example as well (maybe with openssl?) For low level comparison

hugelgupf 9y ago

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 9y ago
> 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 9y ago
  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 9y ago
    Benchmarking the lambda-add latency is something that is useful as long as it's called out as such a benchmark.

IloveHN84 9y ago

It's a pity there's no C/C++ example as well (maybe with openssl?) For low level comparison