hello, I was wondering about the Kryo mechanism: would it not be easier to target Lambda node.js and rely on the Cljs compiler (+Closure) to do all the packaging/tree shaking of cljs code (instead of clj)?

(and that would take care of the startup time as well)

portkey goal was to experiment with a repl-driven workflow (think use cloud resources as a coprocessor for explorative programming, one-off tasks etc), not to deploy “poduction” lambdas. Without this requirement there’s no need for kryo. On JS VMs, there’s no way (unlike things have changed) to examine a closure (to get the closed over values), so no way to serailaze a live graph of objects. Advanced compilation + Closure gives you static treeshaking, while for this repl stuff it was dynamic tree shaking that was required. Graph of code modules vs graph of objects.

Do you see what I mean?

in portkey, you would start tree-shaking from a function object at the repl, closing over whatever state you had in the repl

Graal/native-image gives nice startup time and you can keep the synchronous programming model + Java ecosystem (to a degree that works nice with native-image)

for JavaScript, I think shadow-cljs is a nice option, since consuming npm libs works well and Closure compacts the JavaScript outputted by CLJS + minifies npm libs

the previous two options have both their merrits, but differ from the dynamism that portkey was experimenting with

@cgrand @viesti thanks for the insight, I hadn’t thought of the live aspect of it!

I’m considering experimenting with cljs+aws lambda+terraform for “production” lambdas

btw. Terraform has a nice way of creating Lambda zip file, and upload it if shasum changes

I am aware 🙂