Clojurians Log v2
holy-lambda
ah
yeah, was thinking on background that bb + tasks etc. bring deps.edn closer
I'm taking few days off from work, so maybe this week I will roll out a new release.
enjoy it!
It occurred to me that could never JVM runtimes be supported, by bundling the JVM (maybe in a layer) and having the custom runtime event polling loop run with regular JVM. Probably could still keep the current JVM runtime support, no need to remove it I think. Would add another deploy target though 🙂
Also, just for the record, Ghadi was experimenting with jlink based Lambda a while ago (https://github.com/ghadishayban/lambdaclj-jdk11) and I remember doing some experiments with jaotc (https://docs.oracle.com/en/java/javase/13/docs/specs/man/jaotc.html), but I guess neither of those offer as fast startup as native-image and still introduce some overhead, although maybe smaller than native-image compilation, but native-image probably yields better results overall
@viesti Let me know whether it makes sense.
ah was thinking not using the AWS provided JVM8 runtime at all, but to bundle own JVM version, either directly or via a layer
don't know if AWS at some point upgrades it JVM runtime to other versions, but was thinking that people might want to try using never JVMs at some point too 🙂
things probably break if you compile the bytecode to a newer version which JVM8 doesn't support, so shipping the whole jvm as a custom runtime would then cut it
might be in holy-lambda scope, but don't have to do it immediately, was just a thought 🙂
Hmm... Java runtime stays, but I can provide a layer which includes Clojure + holy-lambda runtime as jars, then I can simply merge classpaths. It will however not impact performance in any matter. What Ghadi did is basically the same thing we're doing in holy-lambda. You can either gen RequestStreamHandler and create a syntatic define which proxies input to wrap-lambda (3 arity wrap-lambda). Or we can use 2 arity wrap-lambda via (native/entrypoint). @viesti You can experiment with jaotc and if you decide the results are promising we can talk about this through. My current roadmap is: • babashka tasks • polish babashka-layer • introduce nodejs runtime
@viesti Of course using java11 is kinda scarry w aws sam since they do some nasty things with loading jars.
I guess Leiningen offers: • way of getting dependencies • way of doing AOT and a uberjar (for native-image compilation) deps.edn then offers: • way of getting dependencies (also git dependencies, which is neat) • Probably be easier to use with babashka (I guess babashka understands a bit about deps.edn and spawning the clojure cli for listing dependencies is faster than with Leiningen) • doesn't have built-in AOT since it's not a build tool, but there are ways around that (provide a task which does something like this: https://github.com/juxt/pack.alpha#aot-for-better-startup-speed, or use a packaging library like https://github.com/seancorfield/depstar#aot-compilation)
I like deps.edn, although it brings a bit of extra for for the AOT compilation 🙂
Actually we will provide both. I now that deps.edn is now preferred, but I don't want to stick to just one build tool.
@viesti I need a deps.edn support to provide a tasks for it: https://github.com/FieryCod/holy-lambda/issues/36#issuecomment-826367331