I am discovering this gem! awesome 🙂

Nice! Perhaps a typo here : >For Clojure on official AWS Lambda Java runtime the cold start is between 8-12on a 2GB memory-sized environment.  -> 8-12s on What is the Clojure on Clojure backend and why is it faster than AWS' Java? I couldn't find it quickly in the docs (though I suppose it's there somewhere..) Also, do you have some benchmarks for all the backend? I've once tried babashka lambda (without HL) and it still had considerable cold start - which I blame on the fact that unpacked it had 140MB (70 bb, 70 jdbc pod) that needed to be transferred and decompressed...

Where will you publish the benchmarks when they're ready? I'm very curious!

@U0522TWDA thanks! Fixed the typo. Will push the change soon 🙂 Clojure on Clojure is basically uberjar + custom Clojure runtime ran on some sort of JVM. This is different than the official AWS Java runtime that: 1. Invokes the handler using reflection based on name, 2. Uses Java Correto (regular JDK users will be in some time pushed to use Java Correto, which works kinda slow for Clojure) (don't know why, yet) Regarding babashka backend HL includes the pods in the zip, so no download of pods happen on runtime. Size of the artifact does not matter much in your case I think. @U09LZR36F Here are benchmarks although not yet edited, and without tiered compilation for Clojure on Clojure, so there will be some significant differences in cold starts i suppose. https://github.com/FieryCod/holy-lambda/tree/master/benchmarks/holy-lambda-vs-other-runtimes Disclaimer: Benchmarks for Java are still using OpenJDK.

Ok, so the Clojure runtime is essentially a Docker image, currently based on OpenJDK, like this one https://github.com/FieryCod/holy-lambda/blob/master/docs/examples/getting-started/clojure-backend/holy-lambda-example/Dockerfile, correct? And it is faster b/c Correto is slower than OpenJDK for Clojure and because reflection on name is faster than whatever AWS does by default? > Regarding babashka backend HL includes the pods in the zip, so no download of pods happen on runtime What I meant was that for cold start, Lambda needs to transfer the whole lambda zip from S3 where it is kept, and the bigger it is the more time that takes. So 1kB Python script will have faster startup than 80MB (22MB compressed) bb (on my PC, unzipping that takes 500ms!)

Clojure runtime is essentially custom runtime, that does not include all the Java'ish bloat, and this is why it's faster. JVM implementation is a user choice, but yeah correto is slow, so by default I'm including openjdk

Regarding babashka I think you're assumptions are wrong. Do you cache jdbc pod? Or do you download the pod on cold start?

I mean 2-3 years ago I have packed 200mb of node_modules and cold start was around 300ms.

My zip included both bb and the pod

Are you sure the pod was not re-downloaded? 😄 I had to do some additional work on HL side to ensure it

And if you're using add-deps you can be sure that cold start is high.

Anyway @U0522TWDA. If you really care about minimal cold starts use native backend. We have some successful stories. Look NextDoc @U0510KXTU 🙂

Thank you. I will experiment with that at the next opportunity. I am quite sure (99.9%) the pod was not re-downloaded as I included it using a local path. I still think that transferring 40-50MB (in my case) and unzipping it is bound to take some time, even if there is a super network between S3 and lambda.

Encourage you to try HL 🙂 Maybe you will see some difference in time 🙂

I don’t use scala, but this is cool as shit. Congrats on the release!

Thanks!

Impressive! (doc links in the readme don't work btw)

Woops! Thanks for pointing that out. The link in the sidebar should work.

that indeed does

Readme links should be fixed now.

First star.

A long time ago I tried to use the Clojure REPL from Scala: https://blog.michielborkent.nl/2016/07/26/clojure-from-scala/ This was during a short adventure in a Scala company.

That is a very interesting idea! I never thought about inspecting the Scala/Java context using an in-process Clojure repl. Very clever.

That's perfect! I added it to the FAQ and credited you. Perhaps one day I will retcon the origins to make myself seem far more clever and cultured than I am. 😄 Thanks!

Nice, i tried to interop with scala code from clojure but gave up

it was too painful, i'll keep this lib in mind

Where would be the best place to ask questions about some implementation details of some of these? I'm wondering why is https://github.com/clojure/clojure/commit/1d271d7bc74f64831985f89be1d814df2c5f046f#diff-313df99869bda118262a387b322021d2cd9bea959fad3890cb78c6c37b448299R7963 not (transient (empty m)) but I don't seem to be able to comment on the Jira

Nevermind, I'll just comment on github

@U08BJGV6E probably @U050WRF8X is the best person to answer this but I believe the difference here is that with update-keys, the keys are going to change and the structure of the map will change, so there is no reason to update the existing map. also, there are lots of potential issues with changing the key set for different map types (like sorted, ordered, etc). In update-vals, the keys stay the same, so the fastest thing to do is update a transient version of the existing map, if you can.

Thanks Alex. It caught my eye as we use https://github.com/frankiesardo/linked which keeps insertion order and it became a habit of mine to use (empty m) everywhere I 'modify' a map without knowing the broader context

Yes! What @U064X3EF3 said ^^^ 🙂

Importantly, the docstrings for both update-keys and update-vals both say "returns a new map" which means you should not presume anything about the relationship of the returned map type and the input map.

I understand the reasoning but (I guess due to the problems I had when the type was lost) still tend to disagree - (empty m) also creates a new map (be it sorted or ordered etc.) so you aren't really 'modifying' the original one (as you would with (transient m)). Apologies for making noise if this has already been considered, I won't pursue this any further, just hoped handling this similarly to update-vals could broaden the applicability of this fn.

tradeoffs exist, this is where we came down on it

Thank you for the explanation