Haskell Runtime for AWS Lambda

aws-lambda-haskell-runtime allows you to use Haskell as a first-class citizen of AWS Lambda. It allows you to deploy projects built with Haskell, and select the handler as you would do with Node.js. It discovers which modules of the project implement a handler for AWS, and generates a dispatcher dynamically, so you don't have to worry about wiring the lambda calls, as it uses the handler name specified in the AWS Lambda console.

It makes deploying Haskell code to AWS very easy:

module WordCount where

import Aws.Lambda

handler :: String -> Context () -> IO (Either String Int)
handler someText _ = do
  let wordsCount = length (words someText)
  if wordsCount > 0 then
    pure (Right wordsCount)
  else
    pure (Left "Sorry, your text was empty")

Then, in the Main module:

import Aws.Lambda
import qualified WordCount

initializeContext :: IO ()
initializeContext = return ()

generateLambdaDispatcher StandaloneLambda defaultDispatcherOptions

Performance

Performance is overall good, meaning that it faster than Java apps on AWS Lambda, but still not as fast as Node.js:

Runtime	Best Cold Start	Worst Cold Start	execution time	Max memory used
Haskell	60.30 ms	98.38 ms	0.86 ms	48 MB
Java	790 ms	812 ms	0.89 ms	109 MB
Node.js	3.85 ms	43.8 ms	0.26 ms	66 MB

A bit of background

We were there when Werner Vogels announced the new custom lambda runtimes on stage, and we couldn’t have been more excited. It was definitely one of our favorite announcements that morning. We have been trying Haskell (and other flavors of Haskell, like Eta and PureScript) on AWS lambda since we started working on Serverless more than a year ago. From the beginning we felt like Haskell fit like a glove in AWS Lambda — it produces fast and reliable binaries and it’s a pure functional language! There’s nothing like a pure functional language to write Lambda Functions, right?

Well, the reality is that Haskell didn’t work as well as the supported languages did. We had to apply ugly hacks to make it work, like compiling an executable/dynamic library and then wrapping it around in a Node.js module that performed a native call. We always ended up switching to TypeScript or other better supported languages for production projects. But now since AWS started supporting custom lambda runtimes, that’s all in the past!

Excited as we are? Keep reading! 👇