<p><pre><code> We are making these open source runtimes available soon:
C++[1]
Rust[2]
We are also working with our partners to provide more open source runtimes:
Erlang (Alert Logic)
Elixir (Alert Logic)
Cobol (Blu Age)
N|Solid (NodeSource)
PHP (Stackery)
</code></pre>
There is also native Ruby support as well[3]<p>1. <a href="https://aws.amazon.com/blogs/compute/introducing-the-c-lambda-runtime/" rel="nofollow">https://aws.amazon.com/blogs/compute/introducing-the-c-lambd...</a><p>2. <a href="https://aws.amazon.com/blogs/opensource/rust-runtime-for-aws-lambda/" rel="nofollow">https://aws.amazon.com/blogs/opensource/rust-runtime-for-aws...</a><p>3. <a href="https://aws.amazon.com/blogs/compute/announcing-ruby-support-for-aws-lambda/" rel="nofollow">https://aws.amazon.com/blogs/compute/announcing-ruby-support...</a>
Several related lambda announcements to around structure/reuse as well:<p>1. Lambda Layers - Reusable components that can be shared across lambda functions (covered in the linked article)<p>2. AWS (Serverless) Toolkits for PyCharm, IntelliJ & VS Code - <a href="https://aws.amazon.com/blogs/aws/new-aws-toolkits-for-pycharm-intellij-preview-and-visual-studio-code-preview/" rel="nofollow">https://aws.amazon.com/blogs/aws/new-aws-toolkits-for-pychar...</a><p>3. Nested Applications Using the AWS Serverless Application Repository - <a href="https://aws.amazon.com/about-aws/whats-new/2018/11/sam-supports-nested-applications-using-serverless-application-repository/" rel="nofollow">https://aws.amazon.com/about-aws/whats-new/2018/11/sam-suppo...</a>
Has anyone seen discussion of the impact of serverless on programming-language <i>design</i>?<p>It relaxes constraints that have historically restricted the shape of viable languages. With massively-parallel deterministic compilation (like Stanford's gg - which just got simpler to implement). Parallel distributed incremental shared type checking, like Facebook's Hack. Language-community-wide sharing of compilation artifacts (sort-of like build images, or typescript's type definition repos, or Coq's proof repo).<p>"That would be a nice language feature, but we don't know how to compile it efficiently, so you can't have it" has been a crippling refrain for decades. "[D]on't know how to either parallelize or centrally cache it" is a much lower bar. At least for open source.<p>This involves not just compiler tech in isolation, but also community organization for fine-grain code sharing. Any suggestions on things to look at?
Way to go, Ruby support!!!! I am irrationally excited about this, if I wanted to do Serverless Ruby up until now, my nearest options were (some community-supported thing with "traveling ruby" on AWS, or...) Kubeless, or Project Riff<p><a href="https://www.serverless-ruby.org/" rel="nofollow">https://www.serverless-ruby.org/</a><p>We've been waiting! I thought this would never happen. Eating major crow today, as I've assumed for a long time that AWS's lack of Ruby support in Lambda was an intentional omission and sign that they are not our friends.<p>I will change my tone starting today!<p>(edit: Or Google Cloud Functions, or probably some other major ones I've missed...)
I'm personally very hyped for using Haskell natively on Lambda! In the keynote he mentions the partner sponsored runtimes, and actually said "Scala and Haskell, you'll just have to bring your own!" (as in, community effort).
Layers sounds like a great solution to sharing code/libraries. If anyone at AWS is here, will there be a way to pull them down for local testing? At the minute it's trivial because you're forced to pull all your dependencies into a single place you can zip them, and you can test them at that point - but will you still have to do that if you want to test locally with layers?
Awesome. Our "Distributed Monolith" problems are now solved.<p>We have so many Lambdas that share common Java JAR libs.<p>Lambda Layers appears to solve our reuse and deployment headaches.
We've been packaging pandas in a lambda which is used to perform some calculations, but being a 50 MB zip file makes cold starts of about 6-8 secs. We're lucky that the service has little use, thus our way to workaround it is by having a lambda warmer which is run every 5 minutes and invokes N pandas lambdas. I'd be very interested in knowing if Layers has some feature to avoid this kind of issue.
Note that it's long been possible to use any language with Lambda through a shim. In the early days that was using Node.js to call out to your binary. That meant you had an extra bit of startup cost (Node + your binary). Once Go was supported that no longer mattered much since Go binaries start almost instantly.<p>Of course an official method is nice here.
Noob question but is it possible/advisable to somehow (re)use prepared statements in Lambda?<p>"Prepared statements only last for the duration of the current database session. When the session ends, the prepared statement is forgotten, so it must be recreated before being used again. This also means that a single prepared statement cannot be used by multiple simultaneous database clients..."[1]<p>1. <a href="https://www.postgresql.org/docs/current/sql-prepare.html" rel="nofollow">https://www.postgresql.org/docs/current/sql-prepare.html</a>
Now, if I can also link the MySQL C++ connector libraries, I could run some of my code "natively" in Lambda.<p>I have used C++ in Lambda before, it is quite cumbersome and it still has the performance hit of using Node.JS.
Forgive the noob question, but why is it necessary to have a custom runtime when using a binary from a compiled language? It seems to me that golang support should just mean binary support, and then c++ and rust would be able to comply already, no?
I am still waiting for proper PHP support and the ability for Lambdas to use VPC to connect to RDS servers, leaving my DBs wide open is kind of annoying... they say its possible but I've had 4 engineers try and no one can get it to work.<p>These issues that Azure has already solved, make me wonder how much longer i will stay with AWS.