Hacker News new | ask | show | jobs
by OJFord 1721 days ago
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.

1 comments

> 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.

>> an optimised compiled binary anyway

> Hence Golang.

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