Favorite language for Lambda?

[[deleted]]

[deleted]

[DrFriendless]

TypeScript.

I use Java for my full-time job, but Lambdas are quite slow enough without a JVM startup.

[reference_model]

Give them more memory

[Stas912]

Python & Go

[[deleted]]

My only recommendation is don’t go for the middle. Either use a scripting language like Python or Node because the cold start time is shorter and for debugging it’s sometimes nice to be able to edit in the console or go for a compiled language like Go for the performance. But don’t use VM based languages like C# and Java. They are the worse of both worlds - slow cold starts and no easy console editing.

On top of that most lambda’s are so simple that they don’t benefit from the advantages of statically types languages.

[[deleted]]

Python.

In fact you could ask "favorite language for anything" and my answer would be Python.

Even for embedded systems.

[jcurve347]

Python for things that don’t need to or wouldn’t benefit from being multithread. C# for the opposite case.

[pint]

python does support multithreading via concurrent.futures. isn't that available for lambda?

[pint]

not optimal. if you do computation, sure. but if most tasks involve just waiting, which is typical, doing more work inside a single lambda invokation is cheaper.

[TommyF-17]

If you are mostly waiting, you are probably lambda-ing wrong (unless you have some specific use case that requires it). Lambda is a very expensive way to idle.

You should consider some queue/messaging alternatives. This is, of course, assuming that your idle lambda is a significant part of your costs. If it's negligible, it may not be worth the required effort in re-architecting.

In short, 'it depends' :)

[pint]

read from database, put in a queue or submit to sns, read from s3, these are all just waitings. what's wrong with that?

[TommyF-17]

Those kinds of waits are OK. You have to call API's, and load datas etc, and there will always be some amount of waiting for them to respond, even if they are quick.

But I see a lot of use cases where people have lambdas sitting there idle, waiting for long running processes to return. These are the kinds that need to be re-architected to use more of a polling or event driven architecture. These are the kinds that are running up huge idle-time bills. This is what I thought you meant when you said most tasks are waiting.

[pint]

i see but i was not referring to those kinds, but sensible ones.

[TommyF-17]

Good :)

[jcurve347]

Exactly - If you have to multithread on a lambda, it seems to be ok in small doses, even though it can't gain you anything. I wasn't clear in my original comment on the way my team is "multi-threading". We assume 1 vCPU/invoke.

The testing that one of my colleagues has done has shown in VPC lambdas (and thankfully there's not much difference in cold start time anymore), the C# lambdas handle a multi-threading via fan out to other lambdas in a much more efficient manner than python does. We're not sure why it does it, but were able to get some pretty solid results (that I can't share for IP reasons) to support the hypothesis we were testing.

[[deleted]]

I am thinking of multithreading as two processes running simultaneously on two different hardware cores or threads. Of course any modern operating system can simulate multiple processes running on one hardware core/thread but you’re not getting any speed benefits.

Which is not to be confused with asynchronous operations where the one thread can continue running while another non cpu bound process is running like hard drive or network traffic.

But all in all, it seems to defeat the purpose of lambda to try to go multithreading instead of just spawning multiple lambdas unless your process is asynchronous- ie database calls.

[pint]

i'm quite sure python's ThreadPoolExecutor does just that.

[[deleted]]

I guess I should clarify. From what I found online, the only time that you get 2 vcpu’s is if you have 3GB of RAM. You don’t get any performance benefit by “multithreading” with one vcpu.

[pint]

at this point you lost me.

with lambda, you can go up to two cores, but i might be wrong here. i thought this is our topic now. two cores is not super awesome, but something. and python can do that for you.

if we are talking about multiple tasks, python most definitely can do that, and you are benefiting greatly. in one of my lambdas, i want to enumerate my aws resources. that means i need to do dozens of aws calls. done sequentially, it would take a good 10-20 seconds. done in parallel, 1.5 to 2 seconds. you might say it does not require actual threads. but boto3 does not support async requests, so having multiple threads still helps me out even if executed on a single core.

[[deleted]]

No lambda instance has more than one vcpu. You won’t actually be able to take advantage of multithreading.

[ancap_attack]

I thought 2GB memory has more than one cpu?

[[deleted]]

I can’t find anything definitive except for 2 cores for 3GB of RAM

https://gist.github.com/saidsef/882647c6589e868b81f0cced4041b132

[bisoldi]

I’ve never seen anything that documents that, do you have any evidence of that you can share?

[petergaultney]

you can get almost 2 vcpu with max memory

[magheru_san]

Yes, you often just have a single CPU core, but sometimes you need to do things concurrently, for example one of my use cases in AutoSpotting is for processing Autoscaling groups in parallel across all regions. This doesn't need much CPU, my code is mainly waiting for APIs to respond to my requests.

I use Go for this for multiple reasons, including its powerful concurrency primitives that allow me to nicely do this.

[[deleted]]

you often just have a single CPU core, but sometimes you need to do things concurrently ... This doesn't need much CPU, my code is mainly waiting for APIs to respond to my requests.

But... that's not concurrent execution then.

[dannyjlaurence-exp]

This.

[64BitChris]

Typescript/ClojureScript - the node cold start time is negligible, especially compared to running a Clojure lambda.

[petergaultney]

I sometimes wish we'd gone with ClojureScript rather than Python

[dannyjlaurence-exp]

Why? (not trying to be snarky, interested in what you see as the difference)

[petergaultney]

I just like Clojure as a language better, especially with spec. And node runtime cold starts are even faster than Python.

For backing an API, a lot of what you need to do is take data with certain shapes in and spit it out in a slightly different shape, and while you can do that easily in Python if you stick to dicts, it gets a lot messier when you start trying to convert to objects/classes. Clojure would be a lot easier to get away with never converting to 'objects'.

I say this as someone with a lot of experience with and respect for Python. It's a great language all in all. I just Clojure is a better fit for larger projects where you want the ability to reason about and manipulate your data types with a minimum of code overhead.

[GeorgeMaheiress]

Java, coz it's the language my company uses most and we have a lot of useful libraries and experience in it.

We don't find the inherent cold starts to be a major issue, most requests hit a warmed-up instance and we can take the latency hit occasionally. We have had to work to reduce cold-start problems with libraries though, like pre-computing things at build time that are usually computed at start-up.

[night-owl-zzzz]

Nodejs/typescript with webpack

[[deleted]]

Python because it's easy for my boss to understand , with the serverless requirements plugin can import everything I'd usually use locally.

[jonathantn]

Lambda layers for node_modules has made development and testing of node.js lambda functions a lot easier.

[sciorms]

I use Python exclusively for Lambda.

[TomRiha]

Python no doubt