Fork me on GitHub
#aws
<
2018-12-03
>
mj_langford20:12:14

@lilactown Yes, there would be a defined, clojure specific runtime with tests and things to build around.

mj_langford20:12:25

That thing could be optimized, integrated with Ring, etc.

mj_langford20:12:08

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.

lispers-anonymous20:12:01

There would be a lot of benefit to using graalvm in lambda.

lilactown20:12:03

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

lilactown20:12:00

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

mj_langford21:12:06

Clojure + keepalive pings is an option

mj_langford21:12:21

Still can be economical for many tasks.

mj_langford21:12:42

I personally want to see a well proven clojurescript stack built on it

mj_langford21:12:06

Waiting for just a bit better shadow-cljs/node doc to happen there myself

richiardiandrea21:12:48

@mj_langford the node-script target already serve that purpose

dogenpunk23:12:07

Anyone using CodeCommit here? Wondering if there are any drawbacks for a private commercial project developed by a small (1-4) team.

aisamu23:12:47

It can be terribly slow at times...

dogenpunk23:12:50

Is that slow on just remote push/pull ops or is it also slow when used in conjunction with CodeBuild/Pipelines as well?

aisamu23:12:51

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.

dogenpunk23:12:42

Right on, thanks!