It’s been more than a few years since an AWS partner released an article about standout languages, and a LOT has changed since then: Lambda functions, language versions, runtime availability in Lambda functions, more focus on microservices…the list goes on and on. So why not revisit the subject? Maybe we can put some more focus on Lambda functions with ours since they’ve heated up a bit since 2014.

Let’s take a look at the same list — in the same order — from the AWS article, and then throw a couple more options on the end for good measure.

.NET (C#/PowerShell)

.NET always seems to be an irreplaceable favorite of at least person in the room, which shouldn’t be surprising considering the fantastic documentation, wide berth of language support, and even now Xamarin — and that doesn’t even take into account that it’s best equal is JVM and everything that comes with it. While full features being restricted to Windows is a drawback that can get in the way of the full .NET experience, it’s not one that can’t be overcome and is getting easier and easier since Microsoft open-sourced .NET.

While .NET supports a multitude of languages the most common one (and the one with out-of-the-box Lambda support) is C#. While C# sees quite a bit of popularity due to its use in things such as Unity, Kentico, and the aforementioned Xamarin, it’s not necessarily your best pick for AWS. It almost goes without saying that Azure provides a more well-stocked toolbox for a C# developer than AWS does and if .NET is an integral/core part of your stack you’d be smart to consider Azure instead. And what about Lambdas? Since C# is a compiled and class-based language, cold start times can be not only painful but detrimental. A distributed app might have to wait 10 or more seconds for an operation to complete if there were 5 Lambdas involved! While cold starts can be mitigated through various techniques, C# misses another point with it’s higher overall memory consumption than an interpreted language. Since you pay more for more memory and C# will want that all the time, expect C# Lambda functions to cost more than their Python or JS counterparts.

What about PowerShell? Outside of the fact that .NET supports PowerShell and C# was already taken, PowerShell can be extremely popular amongst system admins. Most of the examples and guides you can find about using PowerShell in Lambda revolves around sysops and devops, and for good reason! PowerShell was designed to automate tasks, is cross-platform (seriously, it works on macOS and Linux!), and many sysops and devops engineers moving into the cloud space already know it. The syntax and features seem to be just about perfect for these uses.

Of note due to the rising popularity of functional programming: AWS tells us how to get F# going in Lambda.

Java

The story of Java in AWS is very similar to that of C# — without the Microsoft and add the Oracle, of course. It’s a bit “heavy” to be considered a good fit for Lambda functions, it has a committed fanbase, and its ownership is a constant controversy. Despite the questionable life of a Java Lambda function, a Java web server is as well at home in AWS as anything else. If Java is what you know, you can absolutely stay in your comfort zone and utilize AWS.

What is the JVM? The JVM or Java virtual machine, an environment that supports a plethora of languages. And these seem — in general — to work with Lambda functions with no extra configuration. If you prefer Clojure, Groovy, Scala, or Kotlin you can just toss ’em in a Java runtime Lambda and fire away. Depending on your use-case, this might outweigh the slow cold starts and high memory usage of the JVM.

Python

Since the AWS CLI is written in Python, it would be easy to assume a marriage of your Python code and AWS would be a happy one. And that assumption would be absolutely correct. Often used as the holy grail answer of “which language should I learn first”, Python’s code style guidelines give it an edge on developer iteration and help ease the pain of shared code. There are enough guides on the internet to learn Python that you could probably find a combination that would enable a fish to learn the language, and yet it is also capable of powering some of the most intricate and heavy-duty applications. Support of versions 2.6, 3.6, and 3.7 (dear Python community: pick one and stick with it!) mean that even if you can’t use the newest version of Python you can still use Lambda functions. And boy-howdy is Python a great choice for Lambda! It is by far the fastest option with cold starts at every memory level, has fantastic SDK support, consistent documentation, and wide adoption making it an easy choice for a wide array of developers.

Python also gets many many bonus points for being one of two languages in this list that work across all major cloud providers’ serverless functions offerings.

Ruby

Ruby is well loved, even if often thought to be dead. Most any developer who has worked with it can at the very least find something nice to say about it. Many can’t stop saying nice things about it after they’ve started. A lot of that loyalty comes from the Rails framework — yeah, that’s right, Ruby isn’t Rails — a framework that is probably not hard to find being used on an EC2 here or there. Since Rails has always been one of the essential pieces of Ruby, you can expect that its use in Lambda functions would be minimal. And without disparaging Ruby devs…yeah, you’re right. Adoption is so low that even benchmarking is hard to find, though from what I can find it seems to be ahead of .NET and Java but behind Node.js and Python. Apparently, this year is supposed to see some big releases for Ruby including a JIT compiler, so maybe in the future, we’ll see a new frontrunner?

PHP

PHP is…well, it’s PHP. With the release of PHP 7, many people who previously lived their lives with their fingers superglued to their eyeballs can now use both hands and see with both eyes when writing code. And since 80% of the web is powered by PHP, that’s probably a good thing. Despite the hate it gets, PHP is ubiquitous and someone needs to know it for the inevitable day you need to update WordPress. It is probably a safe bet that PHP is a contender for the most used language in AWS, if we’re counting LightSail. Not surprisingly, the PHP SDK is full featured and capable of the same things as any other language’s SDK. PHP will never go away, no matter how many memes we make.

Can you use it in a Lambda? If you must, I suppose.

Node.js

Node.js has come a long way since 2014, helped along by the fact that JavaScript in general has come quite a distance itself. The adoption of JS is a no-brainer: every modern web browser supports all but the most bleeding edge features, the language has continued to adapt and grow through commiunity involvement, and it’s dynamic typing and interpreted nature make it very beginner friendly. Node.js gives us the ability to have all the same features in a full runtime, no browser required. JavaScript is beginning to push out Python in the “first language recommendation” threads, since knowing JS means you’re capable of writing code for just about anything. And AWS doesn’t disappoint in that, making Node.js a first-class citizen (usually… unless you’re looking at documentation, where you’re more likely to find examples in PHP or Ruby than Node.js). You’d probably find more servers using Node.js with something like Express than you would running Ruby on Rails these days.

Lambda support is A+, though Amazon (and all cloud providers, for that matter) has a bad track record when it comes to version bumps. All platforms support 6.1 — which is notably on the verge of end-of-life as of the writing of this article — and all also have at least beta support of 8.1 and the HUGE performance advantages the V8 engine gained in that release cycle. Experimental 10.1 support can be found in Azure, and technically any version can in AWS through custom runtimes or layers if you’re feeling frisky.

More‽

Shell scripting

AKA Bashzshfish/whatever kids these days are doing.

Not suitable for Lambda, but if you deal with Linux EC2s or use macOS or Linux you’d be well served to learn at least the basics. Deploy Lambdas via the CLI, move files around, SSH into that EC2 you just spun up…Bash is a must for all but a select few (Windows-based) cloud-oriented developers.

Amazon States Language

The JSON-like language used to power Step Functions (hallowed be thy name). If you don’t use Step Functions you probably should, and you will absolutely need to get familiar with this oddly off-domain site.

JSON

Not actually “languages”, but you’re going to see a LOT of JSON (JavaScript Object Notation) out there — it powers most of the internet, after all!

YAML

If you’re really lucky, you’ll be graced with the indentation-minded YAML (YAML Ain’t Markup Language) — in things such as CloudFormation templates and Serverless Framework config. Familiarize yourself with the limitations and expectations of these standards and you’ll have a much easier time with just about everything.

Final Note

The best language to use? The one you already know, probably. Despite falling behind in some aspects, C# and Java are still strong contenders in many ways. The cost of retooling and learning a new ecosystem might outweigh the increased cost of Lambda execution time. There are plenty of factors. If you must though, Python and Node.js should almost definitely be at the top of your list. Both continue to grow in popularity and support and excel at many common operations in a serverless architecture. Both are supported in GCP, Azure, and AWS — and many other cloud providers.

Fairly recently, AWS went ahead and released custom Lambda runtimes and Lambda Layers. This makes it possible to execute a Lambda function using just about whatever runtime or language you desire. Performance is not guaranteed and could vary from implementation to implementation. For that reason, take care when reviewing performance metrics you find online. It’s probably safer to stick to official runtimes for important code until you’ve got your own data on how well it works. Outside of that: happy hacking!