5 ms·

AWS Introduces a New JavaScript Runtime for Lambda

41 points by bubblehack3r 3y ago

ttfkam 3y ago
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.
- avandekleut 3y ago
  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.
- pjmlp 3y ago
  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.
  - neonsunset 3y ago
    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-aot.html https://docs.aws.amazon.com/lambda/latest/dg/dotnet-native-a... (fun fact: AWS beat Azure to it with its support)
    - pjmlp 3y ago
      From Amazom themselves, https://github.com/aws-samples/serverless-graalvm-demo https://github.com/aws-samples/serverless-graalvm-demo
  - ttfkam 3y ago
    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.
tony-allan 3y ago
I noticed that you can use QuickJS as en embedded scripting language within Python. [1] https://github.com/PetterS/quickjs https://github.com/PetterS/quickjs
mattashii 3y ago
> 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.
- ricardobeat 3y ago
  QuickJS is well known and has been around for a while: https://bellard.org/quickjs/ https://bellard.org/quickjs/
  - mattashii 3y ago
    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.
sapiogram 3y ago
Is there a writeup somewhere by someone with a slightly stronger command of English?
- mdaniel 3y ago
  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 https://news.ycombinator.com/item?id=39304188
nunez 3y ago
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.html https://docs.aws.amazon.com/lambda/latest/dg/images-create.h... I don't mess with AWS's default runtimes anymore!
bradleybuda 3y ago
As always, emacs did it first: https://lwn.net/Articles/707615/ https://lwn.net/Articles/707615/
jauntywundrkind 3y ago
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.
- pjmlp 3y ago
  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.

41 points by bubblehack3r 3y ago

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.

avandekleut 3y ago
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.
pjmlp 3y ago
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.
- neonsunset 3y ago
  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-aot.html https://docs.aws.amazon.com/lambda/latest/dg/dotnet-native-a... (fun fact: AWS beat Azure to it with its support)
  - pjmlp 3y ago
    From Amazom themselves, https://github.com/aws-samples/serverless-graalvm-demo https://github.com/aws-samples/serverless-graalvm-demo
- ttfkam 3y ago
  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.

tony-allan 3y ago

I noticed that you can use QuickJS as en embedded scripting language within Python. [1] https://github.com/PetterS/quickjs https://github.com/PetterS/quickjs

mattashii 3y ago

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

ricardobeat 3y ago
QuickJS is well known and has been around for a while: https://bellard.org/quickjs/ https://bellard.org/quickjs/
- mattashii 3y ago
  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.

sapiogram 3y ago

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

mdaniel 3y ago
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 https://news.ycombinator.com/item?id=39304188

nunez 3y ago

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.html https://docs.aws.amazon.com/lambda/latest/dg/images-create.h... I don't mess with AWS's default runtimes anymore!

bradleybuda 3y ago

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

jauntywundrkind 3y ago

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.

pjmlp 3y ago
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.