Clojurians Log v2

Yes, Java cold start in a Lambda is horrible: 6-8 seconds for the first invocation is normal for JVM. What you can do is: • prewarm your lambda: make a cron job that will ping it keeping it working. That will cost you something, of course; • Compile your code with native image to have a single binary file. Its start time is instant, like Golang or similar languages • If you don't want to compile, use babashka + .clj files. Babashka starts pretty fast as well

I've got a couple of lambdas compiled with native image: one for a Telegram bot, and another for handling HTML forms. They work pretty nice. Both are done with this repo: https://github.com/igrishaev/lambda (check out the readme file)

Oh I forgot: there is still a public lambda I made for demo purposes! You're welcome to bench it: https://kpryignyuxqx3wwuss7oqvox7q0yhili.lambda-url.us-east-1.on.aws/

Thank you @igrishaev for confirmation of startup times. At least I feel less incompetent now... 😅 General knowledge question regarding clojure -> compile your code with native image; Is there certain kinds of clojure code/libraries/functions which if you use them, pre-compile does not work?

Most of the libraries work with native image nowadays; I recall I had problems with Docjure because it's based on Apache POI, and that's a total Java mess inside. Also, official AWS SDK also fails to compile due to various shenanigence in Java runtime.

There is a repo with a list of Clojure libs tried once with native image. This list is incomplete of course: https://github.com/clj-easy/graalvm-clojure

But as you can see, the most needed stuff is there: json, csv, sql/postgres, hickory, nippy, http clients...

There is also another lambda-oriented project, and the most interesting part is the Makefile to compile and deploy: https://github.com/igrishaev/teleward/blob/master/Makefile

Check out Lambda Snapstart https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html

Wow I didn't know about Snapstart, thank you @valtteri for sharing this. By the way, the page says that container images are not supported while @pieterbreed has mentioned he has a container

I have used crac also for a demo recently, you can basically snapshot the vm state after startup and have it resume in tens of milliseconds. But that means packaging your app as a docker container, and there are some subtleties wrt to what should be done or not before snapshotting (ex networking)

I love the name crac... it is exactly what is sounds like. 👍🏽

are you AOT’ing your code? Unsure how you are building, but if you are just copying source into your uberjar you might get “easy” wins from just compiling

Yes, second the AOT point. Definitely look into that. I recommend, before going the graal route, to try your code AOT'd on JDK 24 or 25 and see where that gets you.

Make sure you bump the Java version for both the container's JDK and whatever JDK you develop with or use to AOT.

still AOT will probably get you nowhere near the startup times of native image or crac

Of course not. But I think the goal here is for it to successfully run in the cloud and not be killed after 10 seconds. And trying AOT is certainly the first waypoint for that if it’s not already done

I'd start with AOT as well. Usually you can get in the 1s range just using that (for hello world)

Also, if you use core async there’s a recent release that might even further speed up compilation times if you have access to virtual threads

I've always run under the assumption that aot "in general" is an anti-pattern, and have therefore avoided it except for the occasional -main - containing namespace. Is there any downside to pre-compiling all namespaces?

generally it's a bit useless, but in some cases it's a necessary thing

ex with lamba (when startup time matters) or if you have to be careful about usage at startup (ex with kube, depending on what your org allows or not)

A fun experiment can be start up a repl with the normal class path and then do (time (require main.ns :verbose))

If you are macro heavy compilation can take up a decent amount of time. And having classfiles around is an easy win in that case

It might not be comparable to native image or crac, but keep in mind that JDK 24 and 25 have done a lot to improve start times. So I think with both that and AOT together, you'll see meaningful improvement.

Regarding the trade offs to AOT, there may be some issues depending on how the compiler is configured. But I don't expect you'd hit those issues with default settings. This might be worth a read: https://clojure.org/reference/compilation

Only word of caution I would give is to not use AOT when building library artifacts. Only application artifacts.

in my experience the AOT problems happen when libraries use AOT. it is reliable when used as an application deploy step

(I will never forget the hours, days lost to errors that could not be deciphered when viewing source, because an AOT artifact was being loaded instead of the source and they did not match)

I have on more question on this thread: Am I doing aot correctly? In my deps.edn I have :paths ["src" "resources" "target/classes"] and in my build.clj I have

(build-api/compile-clj {:basis     project-basis
                        :class-dir "target/classes"
                        :src-dirs  ["src"]})
(build-api/uber {:basis     project-basis
                 :class-dir "target/classes"
                 :main      main-namespace
                 :uber-file uberjar-file})

2025-10-14T07:14:17.697Z + exec java -cp /opt/gometro/gometro-bridge.jar spicyrun.ninja.lambda.runtime
2025-10-14T07:14:24.141Z 169.254.38.181 DEBUG [spicyrun.ninja.lambda.runtime:98] - Starting lambda main process...

Can you inspect the jar and verify you have lots of class files?

And it’s totally possible that compilation speed isn’t what is holding you back. But it’s for sure the first thing to check

yes, it has tons of .class files. 👍🏽

I'm not sure the mere presence of class files is enough to ensure they are being used. Does your main ns have a genclass? Something like this?

(ns clojure.examples.hello
    (:gen-class))

You can create a CDS archive with your uberjar https://gist.github.com/bsless/fb79601eb2bfdee85ebf4663dbc7bb1b

Status update: • I've upgraded everything: jdk25, clojure 1.12.3, all of the maven dependencies • I think I've always had aot classes baked into the uberjar, and so far I've not seen improvement I can say was caused by aot. • This is a big project. The uberjar is now ~130mb. • I've used the suggestion to make a CDS archive, and package this into the container, that serves as the runtime image for the lambda. • The CDS archive is a further ~100mb • The very first cold start (right after a function update) takes around 25 seconds. ◦ I'm not sure exactly what happens with the process space the lambda runs in. Even though the initial events timeout on init, and the logs make it seem like a new process starts up, the JVM itself gets going at some point and starts successfully handling lambda events. • Subsequent requests <200ms • Subsequent cold-starts take around 9 seconds. ◦ I believe the difference between the initial cold start and subsequent cold starts are the container layers being moved around which also takes non-zero time.

I'm learning a lot along the way. lambda is weird execution environment, generally speaking...

Thanks for the update. I'm not super familiar with the implications of the JVM running on lambda, but it's slightly disappointing that JDK 25 plus AOT didn't get you better results. Did you notice any startup improvement when running your lambda container on your local machine?

fyi: perhaps you should switch to (log/infof ...) and other macros that end with "f", debugf, errorf, and so on:

(log/infof "something has happened, id: %s, user: %s, context: %s"
  id current-user context)

Nice, thanks! I'm using something other than clojure.tools.logging, though

Also, it's better to avoid multi-line logs as most of log parses follow the rule: 1 line = 1 log. Some loggers replace \n with a soft break so the log entry stays a single line

Good to know. That also implies that developers can still convert \n in their editor and get something readable. (I've done so for logs I wanted to read and didn't control myself)

I see, so just create a macro like this:

(defmacro infof [template & args]
  `(log/info (format ~template ~@args)))

Do you mean that the macro expansion ensures similar indentation across lines?

I mean, the macro will look like this in your code:

(infof "something has happened, id: %s, user: %s, context: %s"
  id current-user context)

That's a good idea for more easily formatted logs, but I don't think it solves my problem of trying to achieve easily readable code that prints easily readable multiline content 🙂

In my current use case, the print is a result of

(testing (format "This editor-indented code works improperly
           with multiline strings")
  (is (= true false) (format "and so
                       does this")))

> trying to achieve easily readable code that prints easily readable multiline content I'd argue that maybe it shouldn't be done at all. A human-friendly description of something doesn't have to be printed, doesn't have to be logged, doesn't even have to be a part of the code - it can be a docstring or a comment. A log entry semantically is "this happened here, with this context". The "here" and the "context" parts are pretty much solved - the first one via logging macros that add the location and the second one by passing relevant run-time values to the logging functionality. The "this" part's only purpose is to easily distinguish log entries from each other and to maybe more easily locate the original logging statement (line numbers are nice but aren't unchangeable). So instead of "My %s multiline print is great!" "delicious" I would use some structured logging tool with ::multiline-print {:kind :delicious}. Mulog has a great docs on the topic and generalizes logging and tracing, if you're interested.

I'll also weigh in on this; I've found that making log statements with "patterns" in them (like you would get with string concatenation or format) are kindof making things harder for you than it needs to be downstream. The useful parts of a log statement: • a string, targeted at a human • context, in the form of a map of data (timestamp, line-nr, namespace, log level, also request-id, customer-id &c.) I've found it much better to make any log statement produce data (json, gelf &c.) with the human-targeted string part being a constant, with the other pieces of context that would normally have been going into format. just being in the log map data directly. Since the constant-string is really a kind of "log statement identifier" it now also benefits from being short (and not multi-line). This unwinds a lot of complexity when you analyze or query the logs in bulk. An example of this is integrating your logs with Sentry, which will choke if every message is unique, but knows how to handle a map of data just fine. Anyway, good luck 🙂

Good point, @pieterbreed. I tend to make very short log statements with data as a separate map. Our logging library takes care of how to handle that. Another reason to avoid hyperactive string concatenation in general for producing logs or similar is that it makes it harder to find in the code base! I love greppable code. But occasionally I try to create a something that has good dev-ex by virtue of telling you everything you need to know, narrated cohesively through prose. And one of these exceptions prompted my question today. I rarely make highly dynamic testing texts and is texts like I'm trying to today, but the test in question sort of acts as documentation and, preferably, should make it very easy for the reader to understand what needs to be done and to actually do it.

I also from time to time have the same question.

[:pre “int f(int a){
         return a
       }“]

A data reader that does that would be trivial to implement. Or a function, or a macro.

An update; for my purposes, a function that splits the input by \n, calls triml on each line and joins it again, and then calls format with any additional args. was sufficient. Easy enough to make, no worries there, but not built in, which is what I was asking about. And fair enough if there isn't anything built-in, I love the conciseness of clojure.core , I just wanted to make sure I wasn't missing out on anything 🙂