You are quite right, and it is not only about the language, but also the echo system around it that you will need to deal with, which may potentially be a bigger hurdle than the language itself.
Only a subset of the use cases for which you may use lambda is cold start an issue, as well. Yes, if you build (web) API solutions with it, it may be relevant.
There are also a number of use cases where it really does not matter if a potential cold start is a handful of ms or 1-2 seconds.
It is kind of an "old" truth that Python and Node.js/Javascript/Typescript are the ones with the shortest cold start, but there are more languages in roughly the same ballpark nowadays.
Of course, it will vary a bit depending on what is implemented, etc.
To your point though - pick a language + ecosystem that you are comfortable with first (that has good official/unofficial support). If cold starts will be an issue and your primary choice is not good enough, consider an alternative for the use cases where this matters.
Ecosystem – good point!
I have worked with node python and go for years. ( also with perl but that is another story ;) ) In the long run – at least since go changed to modules – developing is faster and easier with go then with Python/ typescript.
Python – having to use pyenvs, need a docker to compile c libs for linux if not working with linux
Node – large node modules, async or callback hells
Both have version issues, the long time usage includes updating to new versions.
Go cross compliles, have a fast and reliable module system and long term compatibiliy.
Just look at the supported lambda languages and their versions. Node x or python y first are depracated, then not supported any more.
Go 1.x is just – supported, for years, no need to change anything
We (my employer) used to develop many of our integration solution lambdas in Javascript, then Typescript (with the occasional Python sprinkled in), but now all new integration solution lambdas are built with Go instead.
You are quite right, and it is not only about the language, but also the echo system around it that you will need to deal with, which may potentially be a bigger hurdle than the language itself.
Only a subset of the use cases for which you may use lambda is cold start an issue, as well. Yes, if you build (web) API solutions with it, it may be relevant.
There are also a number of use cases where it really does not matter if a potential cold start is a handful of ms or 1-2 seconds.
It is kind of an "old" truth that Python and Node.js/Javascript/Typescript are the ones with the shortest cold start, but there are more languages in roughly the same ballpark nowadays.
See also mikhail.io/serverless/coldstarts/aws/, which tends to get updated from time to time with new data.
Of course, it will vary a bit depending on what is implemented, etc.
To your point though - pick a language + ecosystem that you are comfortable with first (that has good official/unofficial support). If cold starts will be an issue and your primary choice is not good enough, consider an alternative for the use cases where this matters.
Ecosystem – good point!
I have worked with node python and go for years. ( also with perl but that is another story ;) ) In the long run – at least since go changed to modules – developing is faster and easier with go then with Python/ typescript.
Python – having to use pyenvs, need a docker to compile c libs for linux if not working with linux
Node – large node modules, async or callback hells
Both have version issues, the long time usage includes updating to new versions.
Go cross compliles, have a fast and reliable module system and long term compatibiliy.
Just look at the supported lambda languages and their versions. Node x or python y first are depracated, then not supported any more.
Go 1.x is just – supported, for years, no need to change anything
Yes, precisely.
We (my employer) used to develop many of our integration solution lambdas in Javascript, then Typescript (with the occasional Python sprinkled in), but now all new integration solution lambdas are built with Go instead.
This has a lot to do with the points you mention.
Would love to hear THAT story :)
Which tools/framework do you use?
For the Typescript parts it used to be Serverless Framework. However, now it is more based on AWS CDK. The CDK covers also a wider range of use cases.
That being said, there is also a lot development for customer solutions, and that depends on what they use also.