4. What language should you use for Lambda?
In this episode Eoin and Luciano talk about programming languages in the context of Lambda. What language should you use? Actually we really answer the question “what languages do WE like to use in the context of Lambda”. Be ready for a lot of strong opinions in this episode!
In this episode we mentioned the following resources:
Hello and welcome to another episode of AWS Bites, the weekly show where we answer questions about AWS in just about five minutes. My name is Luciano and together with me, we have Eoin. And today we have a very interesting question that I really, really excited about, which is what language should you use for AWS Lambda? So I'm going to let you start Eoin, what language do you use for your Lambdas? I'm going to resist the temptation to be opinionated.
Really when you're selecting language, I think the first rule is always pick the language that you know and you're comfortable with, especially if you're starting with Lambda for the first time, there's no point trying to learn too much at once. That said, my own personal favorites for Lambda attempt to be the dynamic languages. So most of the Lambda functions I've written have been Node.js runtime, so JavaScript. And my second favorite would be the Python runtime. But you can use up whatever language you want actually these days. What do you think Luciano? Is there a good set of recommendations for people using Lambda for the first time in what language to start with? Yeah, first of all, I'm not going to resist the temptation to be opinionated.
So I'm going to say use Node.js because in my opinion is the best language, the best runtime in general and in particular for Lambda, it's a very good fit for the way Lambda works. And I've been writing a lot of Lambdas in Node.js and so far it has been working very, very well in terms of both performance and ease of writing and deploying and testing the Lambdas. So that's definitely my favorite.
I got to ask then. So what is it about JavaScript compared to the alternatives? Because if you're coming from a.NET developer background, enterprise Java background, you've got a lot of tools there to help support you. The languages give you type safety and the languages themselves are both very performant in Java when it comes to runtime code execution. Why would you use a dynamic language instead of choosing one of those?
Yeah, I think in particular with JavaScript, the main benefit is that the bootstrap time of your Lambda is very well optimized. Like the Node.js runtime starts very, very quickly and this is something you should care a lot when writing Lambdas because of course you want to minimize that cold start time every time you are spinning up a new Lambda. So with languages like Java, I've seen that generally you tend to have much longer cold starts and in Java you have... I suppose that the trick is always the same even outside the scope of Lambda. With Java it's very good if you're doing like CPU intensive type of operations while Node.js tends to be much better if you're doing a lot of IO. And in Lambdas generally I've seen you write a lot of integration code. So most often you end up doing HTTP calls or connecting to external sources. So much more IO than you do CPU intensive tasks. So maybe that's why I've seen Node.js being a much better fit compared to languages like Java.
Isn't it strange though, the way when Node.js became initially popular a number of years ago, it was because of its ability to handle many multiple requests at scale because of how it worked with asynchronous IO and handling multiple connections on a single server. With Lambda, it's always handling one single event at a time. So how is it that this model translates well? Is it just because it's JavaScript? Do you just have to... Do you just dispense with a lot of the advantages of Node.js and it still doesn't matter?
Yeah, I think you are touching a very good point and I think this is a common complaint from many people using Lambda, especially for the first times that if you are getting multiple requests at the same time, you will see multiple Lambdas spinning up, even though Node.js, if you had one server, would be very capable of handling even thousands of connections at the same time. So definitely that's an interesting technical choice and I've heard different reasons from AWS why that's implemented that way. For instance, isolation, if your Lambda crashes, you are not going to affect other users asking, taking other requests at the same time, which could be an interesting point. To answer your question, whether you are losing the benefits on Node.js, maybe partially so, but at the same time, you are still keeping the main benefit that if you're doing a lot of IO, you can easily use the synchros model of Node.js and JavaScript and avail of that concurrency in a very easy way. So if your Lambda needs to connect to multiple places and do multiple things for a given request, you can still do that in a very efficient way.
Okay. So we've talked about JavaScript, Python, I think, you know, they get all the benefits of being able to rapidly develop. You don't have a compile step. They start quickly. I think Java,.NET are reasonable options these days too, because there are ways to manage cold start issues. I think.NET itself is quite performant, the.NET core runtime. What about other languages? Because last year we had the arrival of Lambda container image support. So anything that can run in a container can now run Lambda code. And before that we had custom run times, which was the ability to do the similar kind of thing with a zip packaging. So what other less frequently used languages would you be using in AWS Lambda?
Yeah I think there are two that I am particularly excited about. One is Go, which I actually had the chance to use it. And it's actually supported quite well by AWS these days. And the reason why I use it in the past is because I actually had to do a CPU intensive task. It was a lot of data transformation and I was doing that in Lambda in Node.js. And eventually we realized that in our entire pipeline that was one of the main bottlenecks and we could probably try to do something to speed it up.
We rewrote that in Go and it was like 10 times faster. So that was definitely a very interesting experiment and I was very happy to how easy it was to write and test and ship a Lambda in Go, which was actually quite unexpected. I was expecting a lot more friction. Another one that I'm really excited to try, I haven't tried it yet, is Rust, which is not officially supported as a runtime yet, but there is a very good package that is provided by AWS itself that you just use it as a Rust crate. And then when you build your executable file, it's already called Bootstrap. And that's really the only file you need to put in a zip package or Docker container. You just ship it as a Lambda and it should work out of the box. And they give you all the nice, in the library, they give you all the nice things that you expect to handle, the context, the event, exceptions. So that seems to be a new interesting contender if you really care about performance and quick Bootstrap times. So really excited to have a chance to try that out.
One of the considerations I think it's worth also thinking about, and I think we always fall into the pattern of thinking of how will it perform at production time, but we forget as developers that performance and developer time and your developer feedback loop and how quickly you can deploy, test and iterate is really important. One of the things I observe is that with the most popular tooling for building and deploying Lambdas these days is still the serverless framework. And it seems in my experience, at least to have a strong bias towards Node.js as the best supported runtime for packaging all your node modules and everything else. Even if you start using Python, then shipping your dependencies has a little bit more friction. Have you noticed that?
I did. Yeah. And I've been working a lot with Python Lambdas lately. And yeah, it seems a little bit more complicated than it used to be with Node.js. I think it's something that is going to get better over time because of course the tooling and the ecosystem are always evolving and Python is a widely used language. So I expect that the future is going to be greener, but right now I will agree with you that Node.js is probably the easiest way to get started with Lambda, especially if you already know JavaScript.
Yeah. It looks like AWS Sam has a little bit more, I suppose, of a cross language support, at least for the common runtimes and Python in particular, but maybe that AWS Sam versus serverless framework is a question for another day.
Yeah. Yeah. I'm looking forward to try to answer that one. But for today, that's all. And thank you everyone for listening. We are really curious to know what's your favorite language for Lambdas. So please leave us a comment or reach out to us on Twitter and make sure to follow and subscribe so we can see you next time. Bye.
Use the arrow keys to move between transcript segments, Home or End to jump to the first or last segment, and Enter to seek in the video.
Help us to make this transcription better! If you find an error, please submit a PR with your corrections.