Difference to aws-lambda-haskell-runtime?

[nomeata]

hal was recently highlighted on the Haskell Foundation slack, and got me curious. I am using https://theam.github.io/aws-lambda-haskell-runtime/ / https://github.com/theam/aws-lambda-haskell-runtime for my (few and small) Haskell on Lambda projects, and I wonder how the two related.

Are they comparable? Any benefits one way or the other?

[IamfromSpace]

It’s a good question! One I’m not totally sure how to answer.

Both libs came out at basically the same time, as there was immediate mutual excitement for provided runtimes enabling Haskell—the other was even published a little sooner. We even had a bit of correspondence about how we might consolidate efforts, but it wasn’t ever quite clear how.

The main goal of this lib was always to enable a bring-your-own-monad approach via Monad Transformers, plus some small adapters that enabled an easier start for when you didn’t want to deal with them. That opened a door for others to build some cool stuff like the Wai adapter.

I hesitate to speak for someone else’s lib, but the main offering and investment I see is ease of use. They’ve got some really great docs setup and some things to help bootstrap.

To me, it seems like they both have their use cases. I think hal may be able to take a user further, but may not be quite as easy for some of the most common cases.

Our goal was just to enable more Haskell, so we’re happy if you use either!

[nomeata]

Thanks for the summary! I’ll cross link this to the aws-lambda-haskell-runtime repo. Feel free to close if you like to keep the issue list tidy (or maybe the README should actually have a friendly pointer to the alternative to help new users decide)?

[mbj]

BTW I had a reason to hadn roll my own runtime, mostly as I needed better exception handling control, especially being able to let the runtime crash and NOT re-use a container on an unexpected container.

The undocumented work is here: https://github.com/mbj/mhs/tree/main/lambda-runtime

[IamfromSpace]

@mbj oh interesting, so the difference is that the client throws an exception that the user may catch, and in doing so, they can report on these errors or even prevent the error from crashing the lambda and then continue using the container?

I’d be curious about the ways you use that. I think in theory it would be a non breaking change to hal, just given how exceptions work, but it does seem like quite a glimpse under the hood.

[mbj]

report on these errors or even prevent the error from crashing the lambda and then continue using the container?

no the default is to kill the container, that was the main motivation.

Users can have specific exceptions they may allow the container to continue, but the default is inversed to crash. Which is much better IMO.

Each time I get an unexpected excpetion I have to assume my environment is infected and I cannot just re-use it silently.

[mbj]

And I needed native xray intgration.

[mbj]

Plus I had a disagreement with hal on timeouts on the HTTP poller, IMO they should not exist at all ;)