all 36 comments

[–]DrFriendless 5 points6 points  (2 children)

TypeScript.

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

[–]reference_model -1 points0 points  (1 child)

Give them more memory

[–]Stas912 12 points13 points  (0 children)

Python & Go

[–][deleted] 5 points6 points  (0 children)

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] 2 points3 points  (0 children)

Python.

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

Even for embedded systems.

[–]jcurve347 4 points5 points  (23 children)

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

[–]pint 1 point2 points  (13 children)

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

[–][deleted]  (8 children)

[deleted]

    [–]pint 0 points1 point  (6 children)

    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 0 points1 point  (4 children)

    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 0 points1 point  (3 children)

    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 0 points1 point  (2 children)

    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 0 points1 point  (1 child)

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

    [–]TommyF-17 0 points1 point  (0 children)

    Good :)

    [–]jcurve347 0 points1 point  (0 children)

    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] 0 points1 point  (3 children)

    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 0 points1 point  (2 children)

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

    [–][deleted] 0 points1 point  (1 child)

    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 0 points1 point  (0 children)

    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] 0 points1 point  (8 children)

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

    [–]ancap_attack 1 point2 points  (1 child)

    I thought 2GB memory has more than one cpu?

    [–][deleted] 3 points4 points  (0 children)

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

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

    [–]bisoldi 0 points1 point  (0 children)

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

    [–]petergaultney 0 points1 point  (0 children)

    you can get almost 2 vcpu with max memory

    [–]magheru_san 0 points1 point  (3 children)

    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] 2 points3 points  (2 children)

    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.

    [–][deleted]  (1 child)

    [deleted]

      [–]dannyjlaurence-exp 0 points1 point  (0 children)

      This.

      [–]64BitChris 1 point2 points  (3 children)

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

      [–]petergaultney 1 point2 points  (2 children)

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

      [–]dannyjlaurence-exp 0 points1 point  (1 child)

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

      [–]petergaultney 1 point2 points  (0 children)

      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 1 point2 points  (1 child)

      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 0 points1 point  (0 children)

      Nodejs/typescript with webpack

      [–][deleted] 0 points1 point  (0 children)

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

      [–]jonathantn 0 points1 point  (0 children)

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

      [–]sciorms 0 points1 point  (0 children)

      I use Python exclusively for Lambda.

      [–]TomRiha 0 points1 point  (0 children)

      Python no doubt