Make Feral more amenable to SnapStart optimization? about feral HOT 1 OPEN

Thanks, @kubukoz recently brought this to my attention as well.

If someone wants to experiment with this I am certainly open to making changes that will improve the experience, although at the moment it's not really obvious to me why they would be necessary.

As you point out, if you have some stuff that you would like captured in the snapshot you can just define an ordinary val.

However, this is icky if the things you are initializing are in IO. But the reason things are in IO is because they are side-effects and I am skeptical it you can snapstart these things at all.

For example, see the "compatibility considerations" in the snapstart documentation, which warn about:

Uniqueness If your initialization code generates unique content that is included in the snapshot, then the content might not be unique when it is reused across execution environments.

Network connections The state of connections that your function establishes during the initialization phase isn't guaranteed when Lambda resumes your function from a snapshot.

Temporary data Some functions download or initialize ephemeral data, such as temporary credentials or cached timestamps, during the initialization phase.

https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html#snapstart-compatibility

All of these things are side-effects you acquire in IO and are unsurprisingly exactly the sort of thing you cannot or should not snapstart.

Meanwhile, I suspect the sorts of things you can safely snapstart will not be in IO (since they are not side-effects). In which case, you can just define a val :)

from feral.