@lilactown Yes, there would be a defined, clojure specific runtime with tests and things to build around.
That thing could be optimized, integrated with Ring, etc.
Right now it's yolotown, with everyone copying things partially or making frameworks, etc, where really a buildpack config might be a more minimal, stable, and dependency free situation.
There would be a lot of benefit to using graalvm in lambda.
I'm on board the the developer experience improvements. but back when I tried it, the cold start times of a Clojure lambda was just too much
unless graalvm or what @chris_johnson said where we can optimize the Clojure runtime load process can be done, I still don't see much future of Clojure + Lambda
Clojure + keepalive pings is an option
Still can be economical for many tasks.
I personally want to see a well proven clojurescript stack built on it
Waiting for just a bit better shadow-cljs/node doc to happen there myself
@mj_langford the node-script
target already serve that purpose
Anyone using CodeCommit here? Wondering if there are any drawbacks for a private commercial project developed by a small (1-4) team.
It can be terribly slow at times...
Is that slow on just remote push/pull ops or is it also slow when used in conjunction with CodeBuild/Pipelines as well?
Or both?
I can't say for the Pipelines, since they lacked per-branch build or something like that the last time I investigated. Just push/pull, to the point I thought something was broken on my end.
Right on, thanks!