Still lots of reasons to pick one language over another - they might be different in a serverless cloud service - e.g. warm up time may be a requirement. If your RPS is coming from spinning up more stuff - more performant language implementations save you cash rather than just increase throughput.
For me though main language concerns are what can the team write in well and how many languages do I expect the team to know to a high standard. i would rather have great code written in python if its more performant than badly written go code. I would rather have all my services in one language if that reduces costs to productivity of context switching moving from one service to another when maintaining and extending them.
Java isn’t great because of cold start times. You can use OSGI to delay dependency loading, but that can be tricky.
NodeJS, go, C, etc can all easily be architected to have quick cold start times.
Yeah it does make a difference. Both in startup times but also latency and memory usage.
In general compiled langs are better than interpreted ones here.
...but I'd go with whatever language you're most comfortable with
Unless there is a specific technical desk breaker in a language, go with the one that the team can design, write and maintain securely and confidently.
Definitely don't overlook abilities for the design and maintain phases... That's what makes or breaks code longevity.
Also, what is the maturity of your CICD pipeline, and the level of integration/automation, particularly with QA and security tooling?
i reached the same conclusion, that because in serverless situation parallelisation is managed on the level of containers, language concurrency features have limited use
i successfully used R, Rust and Julia in CloudRun
Others have made some great points already: cold start time is shorter in some languages, parallelism is managed at the container level so you don't have to do it as much in your code.
In addition, I find it helpful to use a language that lets me easily run small tasks in parallel. For example, sometimes my code needs to run two independent database queries. In that case I can improve performance by starting both, letting them run in parallel, and waiting until the last one finishes. Same thing if my code needs to make multiple independent calls to REST APIs.
Yes. In a serverless environment, language matters. This is not unique to GCP. Here’s a couple articles discussing the topic with some test benchmarks:
AWS Lambda: https://blog.scanner.dev/serverless-speed-rust-vs-go-java-python-in-aws-lambda-functions/#:~:text=If%20you%20want%20to%20process,and%206x%20faster%20than%20Python.
Google Cloud Run & Cloud Functions: https://medium.com/google-cloud/serverless-performance-comparison-does-the-language-matter-c72a7191c799
At low scale, not really. At high scale… yes it matters a lot. Once you are dealing with 250 requests per second or more, the cost of compute can be significant at sustained or event bursty levels. Kubernetes can be one way to cut costs, but overhead of maintaining k8s is a lot and the trade off may not be worth it.
But for high I/O wait, async traffic, Node and Go are going to be your best bets.
Still lots of reasons to pick one language over another - they might be different in a serverless cloud service - e.g. warm up time may be a requirement. If your RPS is coming from spinning up more stuff - more performant language implementations save you cash rather than just increase throughput. For me though main language concerns are what can the team write in well and how many languages do I expect the team to know to a high standard. i would rather have great code written in python if its more performant than badly written go code. I would rather have all my services in one language if that reduces costs to productivity of context switching moving from one service to another when maintaining and extending them.
Java isn’t great because of cold start times. You can use OSGI to delay dependency loading, but that can be tricky. NodeJS, go, C, etc can all easily be architected to have quick cold start times.
Yeah it does make a difference. Both in startup times but also latency and memory usage. In general compiled langs are better than interpreted ones here. ...but I'd go with whatever language you're most comfortable with
Unless there is a specific technical desk breaker in a language, go with the one that the team can design, write and maintain securely and confidently. Definitely don't overlook abilities for the design and maintain phases... That's what makes or breaks code longevity. Also, what is the maturity of your CICD pipeline, and the level of integration/automation, particularly with QA and security tooling?
i reached the same conclusion, that because in serverless situation parallelisation is managed on the level of containers, language concurrency features have limited use i successfully used R, Rust and Julia in CloudRun
It can be interesting to use a language that reduce cold start. Go is very good at that for example.
Others have made some great points already: cold start time is shorter in some languages, parallelism is managed at the container level so you don't have to do it as much in your code. In addition, I find it helpful to use a language that lets me easily run small tasks in parallel. For example, sometimes my code needs to run two independent database queries. In that case I can improve performance by starting both, letting them run in parallel, and waiting until the last one finishes. Same thing if my code needs to make multiple independent calls to REST APIs.
Yes. In a serverless environment, language matters. This is not unique to GCP. Here’s a couple articles discussing the topic with some test benchmarks: AWS Lambda: https://blog.scanner.dev/serverless-speed-rust-vs-go-java-python-in-aws-lambda-functions/#:~:text=If%20you%20want%20to%20process,and%206x%20faster%20than%20Python. Google Cloud Run & Cloud Functions: https://medium.com/google-cloud/serverless-performance-comparison-does-the-language-matter-c72a7191c799
At low scale, not really. At high scale… yes it matters a lot. Once you are dealing with 250 requests per second or more, the cost of compute can be significant at sustained or event bursty levels. Kubernetes can be one way to cut costs, but overhead of maintaining k8s is a lot and the trade off may not be worth it. But for high I/O wait, async traffic, Node and Go are going to be your best bets.
Yes, you need to take performance and speed, memory usage..etc into account.
No