One of most question I receive is "which programming language is the best for serverless?". People want to know what's the best choice to create their functions in AWS Lambda. But for me, the answer is not that simple just looking for technical stuffs.
In terms of performance, there are programming languages that perform better than others. The main characteristic that differs to those programming languages is the cold start. If you don't know, cold start is an amount of time that your cloud provider spent to start a new instance of your function. Once your function instance is started, the cold start will not occur for the next execution (until the timeout).
It's known that programming languages based on JVM, like Java, have a higher cold start. But Java has a good performance when the function is warmed up. It's also known that interpreted languages and compiled languages have a better performance in terms of cold start. That's the case of NodeJS and Python. These two programming language have a lower cold start.
So, if we think only technically, the answer is simple: use NodeJS or Python. But, as I said before, it isn't that simple.
For me, developing a serverless application isn't only a technical choose. It's especially about lead time, time to market and a better use of resources.
When I talk about lead time and time to market, that means it's important to care about how much time you need to develop your application. It's common to hear quotes like "faster companies won over big companies" and, because of that, it's important to think about how to build your application faster.
About better use of resources, when we develop our application faster it means we use less development resource. It's also important to think about maintenance, because once launched the application you need to keep that in the air, fix possible bugs, etc.
Thinking on all those things, I decided to create a diagram that help you to choose a programming language for your serverless function.
Choosing a programming language
First of all, I want to clarify that's my own opinion, and it isn't a bullet silver, but I believe it will help you in most cases.
According to the image above, I prefer to use a programming language that the team knows instead of a "better programming language". I did that because I believe in most cases the time to market is more important than the performance. There are many cases when we use functions in an event based architecture and those events are asynchronous. Besides that, even when the function in synchronous, for many times those functions will be warmed up, so we mitigate performance problems.
Using a programming language known by your team, you will develop your application faster (better time to market and less resources), and you will maintain easier because the programming language is in the comfort zone.
If you need to rewrite some function in the future because of performance, it's easy, just because serverless functions are decouple by design.
Conclusion
Of course, if we have an opportunity to use an appropriated programming language in terms of performance it will be great, but I really believe in time to market first.
Cover image by Luis Gomes on Pexels.
Top comments (10)
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.
Agree 100%... in practice the cold-start problem is unlikely to be a real problem. As you should be focusing on edge cacheing data that doesn't change where possible, and if your application has modest use then your baseline # of functions should stay warm.
There are already so many "excuses" people make up for why they can't/won't adopt serverless, let's not make the language one of them.
Great read :)
Yes I don't think cold start is a real problem. People should always choose their language where they can solve their problems best or feel most comfortable with
Nice post!
And - What’s your argument not to include another fast and easy language with long term compatibility (without mails from AWS about „your lambda node|python version ist not longer supported) - GOLANG
Ok, usually it’s just „we don’t know GO“. But a strictly typed language (yes Java and C# too, maybe TypesScript) helps avoid programming errors.
Yes this is great! It's about time we got beyond shiny object syndrome and focussed on writing code that's actually maintainable by the whole team, not just that one person who went to the ShinyX conference last month...
Can you explain this sentence please?: "It's also known that interpreted languages and compiled languages have a better performance in terms of cold start. That's the case of NodeJS and Python. These two programming language have a lower cold start."