AWS Introduces a New JavaScript Runtime for Lambda | Hacker News Reader

AWS Introduces a New JavaScript Runtime for Lambda

i-programmer.info

41 pointsbubblehack3r16 comments

Can't wait for LLRT to be marked stable. Was spending time looking into Rust lambdas, but was reluctant about the total build times for my stacks and getting new team members onboarded with lambdas. (Though in fairness, Rust lambdas tend to be short and digestible, which are perfect for Rust novices.)

LLRT is basically no learning curve. Same old esbuild most TS and JS devs are used to. I guess we're sticking with one language from front to back again:

CDK in TS, lambdas in TS, and frontend logic in TS.

This is how I did it at my previous job. A clever setup allows you to have frontend/backend end-to-end type safety. We even made our lambda environment variables typed, through to the CDK code that populated them.

Yeah, but don't expect the same execution speed or memory consumption.

In fairness I would rather pick Go, C# with Native AOT, or Java with GraalVM, if Rust build times are such a pain point.

Keep the performance of compiled languages, with faster build times, no need to switch to a bare bones interpreter.

I could not find GraalVM Native Image references in official AWS documentation so it may be a scenario that requires work on the user’s end.

Native AOT OTOH has first-party support and is the recommended deployment target: https://docs.aws.amazon.com/lambda/latest/dg/dotnet-native-a...

(fun fact: AWS beat Azure to it with its support)

From Amazom themselves, https://github.com/aws-samples/serverless-graalvm-demo

90% of the time, our lambdas are just making AWS SDK calls or querying data stores like Postgres, Redis, and DynamoDB. The limits are in memory consumption or raw CPU processing but network and service latencies. Those are precisely the workloads where Rust (or Go) can't provide much benefit. The only drawback really was Node's cold start times and JIT overhead that was never really used. Python was faster, but a similar story.

LLRT gives the quick dev and deployment time, automatic OS and SDK updates (when using a zip rather than Docker image), and very low cold start latencies. The rest is nothing much more than await-ing network responses.

Obviously if it were calculating millions of hashes, rendering images, and other similar tasks, I'd run to Rust or Go. But the default looks to be LLRT.

Any larger program with thousands of lines of code or more wouldn't be in TypeScript. But for a twenty-line lambda, especially with JSDoc that has no separate build step? No brainer for me in terms of cost-benefit.

As always, emacs did it first: https://lwn.net/Articles/707615/

This post is a reminder that you can run anything on Lambda if you're willing to run it as a Docker container! https://docs.aws.amazon.com/lambda/latest/dg/images-create.h...

I don't mess with AWS's default runtimes anymore!

Also though, this is a gross gross mis-optimization. Every tenant having to carry their own runtime is a huge cost penalty. That it's a much less cost? Fine great wonderful, yeah. But there should be much much much more ability to share runtime & ideally modules too. V8 isolates & wasm sandboxed modules hopefully can deliver on a thicker runtime, but which doesn't require each tenant to host the world themselves. That is never going to be fast or good or to your scale-to-zero advantage. We can should & must explore better.

And with a JIT.

With the world watching in dismay Python being the last dynamic language standing to finally adopt a JIT into their reference implementation, is kind of strange to take it out of the picture.

Is there a writeup somewhere by someone with a slightly stronger command of English?

the original post from a month ago may help you, depending on how much "blog" you're looking for from the experience: https://news.ycombinator.com/item?id=39304188

I noticed that you can use QuickJS as en embedded scripting language within Python.

[1] https://github.com/PetterS/quickjs

> This also means that its size is tiny, in the order of a few kilobytes in contrast to the 20+MB required by its counterparts.

A full, performant ES2023 runtime, in "the order of a few kilobytes"? Even when you remove all JIT and GC, that sounds too fantastic.

I'll believe it when I see it.

QuickJS is well known and has been around for a while: https://bellard.org/quickjs/

Sure, but as the linked page mentions, QuickJS is 210KiB, which is seemingly larger than "in the order of a few kilobytes" claimed by the subject's blog post.

Reply on news.ycombinator.com