[rewma]

Well, call me surprised. Personally I never bothered using Python runtimes in a production environment, mainly because NodeJS is widely described as pretty much the ideal lambda runtime, and as far as I know there is absolutely no compelling reason to pick Python over it.

Also, for performance undoubtedly Golang is by far the optimal AWS Lambda runtime.

Consequently, I see NodeJS in every single application ever as pretty much the default runtime, with a bit of Java (renowned for being by far the worst AWS Lambda runtime) primarily to leverage code reuse and of course Golang.

If anyone reading this picked Python for your AWS Lambda runtime, do you mind telling why? I would love to hear your rationale as I'm sure I'm missing an important take.

[OJFord]

Ours are all python, none node. In many cases they replaced existing (non-Lambda) python code, though others were green. Why rewrite the code, or switch to node for greenfield stuff? We'd need a compelling reason to adopt node, not to avoid it.

I assume the answer's roughly the same for anyone - it's odd to me that you're talking about 'ideal Lambda runtime', I'd be surprised if many people care. You're going to choose your language by however you were going to choose your language otherwise, and then run it on Lambda. And python is more popular than node in general.

If you really wanted every last gram of performance, you'd be running an optimised compiled binary anyway, not using any of the provided runtimes.

[rewma]

> Ours are all python, none node. In many cases they replaced existing (non-Lambda) python code, though others were green. Why rewrite the code, or switch to node for greenfield stuff? We'd need a compelling reason to adopt node, not to avoid it.

That's a great point. I admit I followed the same exact rationale motivated by code reusie to go with Java runtimes in projects that consisted mainly of peeling responsibilities out of legacy Java services, and Java is notoriously by far the worst performing Lambda runtime.

Granted, this was before lambda's pricing granularity was updated from 100ms down to 1ms. Nowadays, a JDK invocation easily costs 50x the cost of a NodeJS lambda invocation, not to mention the concurrency consequences.

> I assume the answer's roughly the same for anyone - it's odd to me that you're talking about 'ideal Lambda runtime', I'd be surprised if many people care.

Sure, there are other constrains and requirements, but in the context of AWS Lambdas, and taking into account the way they are priced and the fact that they run on a single vCPU and that they are mainly IO-bound, NodeJS is very hard to beat. If you're starting out a project, you're not totally ignorant regarding AWS Lambda's pricing, and you are free to pick whatever runtime you want, it is very hard to justify any rational choice other than NodeJS or, alternatively, Golang.

> If you really wanted every last gram of performance, you'd be running an optimised compiled binary anyway

Hence Golang.

Meanwhile, NodeJS gets you about 90% where Golang takes you without taking a single step outside of the happy path.

[OJFord]

>> an optimised compiled binary anyway

> Hence Golang.

Sure. Or rust, C++, C, .. whatever.

[dagw]

If anyone reading this picked Python for your AWS Lambda runtime, do you mind telling why? I would love to hear your rationale as I'm sure I'm missing an important take.

Libraries and code reuse. Python has libraries for everything, and we have written a whole host of Python libraries of our own. We know how to do what we want to do in Python and many of our lambda functions started their life in either python CLI scripts or as part of a Flask app. "Copy pasting" working code into AWS Lambda is much quicker and easier than rewriting in Node or Go.

If we're 'moving' to anything it would be moving some functions to C(++)

[0xFF0123]

We work with machine learning and computer vision stuff, so python is our language of choice for the main codebase (which is non-lambda). Given that, it makes sense to stick with python for lambda related things for code reuse and lower cognitive overhead.