If I read it right, the point the author is making is that a language with syntax support for concurrency (such as Go) is a more cost-effective choice for a serverless architecture than a language that doesn't (such as JS) because you can perform multiple tasks at once in a single Lambda instance, ex. querying 15 AWS regions per instance rather than creating 15 instances that query 1 region each.
I'm skeptical why this would not be possible in Javascript as well on a single Lambda with continuation passing or async/await, unless I'm missing something fundamental about the serverless JS runtime, or the author is only pointing out Go's readability advantage.
The point I was trying to make was to disagree with someone who was was saying Node doesn't make sense for Lambda because you should only be doing a single task.
I absolutely think Go is more readable, but as you say Javascript can do this fine too.
3 comments
[ 4.5 ms ] story [ 21.0 ms ] threadI'm skeptical why this would not be possible in Javascript as well on a single Lambda with continuation passing or async/await, unless I'm missing something fundamental about the serverless JS runtime, or the author is only pointing out Go's readability advantage.
I absolutely think Go is more readable, but as you say Javascript can do this fine too.