It's certainly easier to figure out what's going on in a smaller container though! I've had to debug some nasty situation with layers in Python Lambdas before and it's not fun...
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.
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.
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.
> Hence Golang.
Sure. Or rust, C++, C, .. whatever.
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(++)
But NodeJS is second!