3 ms·

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 ne

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

by ttfkam 3y ago

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.