Fork me on GitHub

A goo, blustery morning to you all! ( I refer to the weather, not politics)


Morning morning


From the polls yesterday, compojure unsurprisingly comes out on top in terms of what people use at work... but ehhh I'm reticent about how future proof that is to teach


Then again maybe it doesn't matter, once you know compojure you can pivot and learn something else


@alex.lynham does compojure work on cljs too ?


(for some reason i thought you were asking about cljs stack)


but you didn't include #yada on your poll

4️⃣ 10

No I guess you'd write your backend using it and then use secretary or what have you in your cljs


Bore da pawb! welsh_flag


Morning All

👋 10

@dominicm that's a great post

❤️ 5

Does anyone here use clojurescript for server side?

👂 5

I think the juxt-icians were, but have now stopped (or are looking to stop), but I think that was b/c node was a pain


what's the pain with node juxt-icians ? @dominicm ?


for me its clojurescript graphQL server 😮

Wes Hall12:02:38

cljs+node servers....


but as a serverless execution engine for cljs node makes quite a lot of sense, given how long it takes a clj app to spin up

Wes Hall12:02:19

@mccraigmccraig Yes, actually those are the kind of practical considerations that actually qualify as, "thinking whether or not you should". If you are doing AWS Lambda, and have latency considerations (your lambda functions are responding directly to user HTTP requests for example), then I think that constitutes valid justification.


oops, my mistake - i thought you were dismissing it as generally wrongheaded 😬

Wes Hall13:02:12

No not really. I would have the policy of defaulting to clj on the server and cljs on the (web) client, unless there was a very good reason to use cljs on the server (and your example qualifies). The problem, in general with cljs+node servers is that you very quickly have to move out of the clojure ecosystem and start scripting JS frameworks with interop, because it's just not well supported. Only a small number of the primary choices in the clojure serverside game are cljs/cljc supported. Clojure on the server just gives you so many more good options.


sure, i don't imagine you would have an easy ride

Wes Hall13:02:00

I would add that, for the most part, there is a reason why the JVM takes a bit longer to fire up than node, and most of those reasons are things you want in your serverside application 🙂.


to be fair to the JVM, it's not really the JVM - the JVM is pretty quick to start these days - it's clojure imposing most of the load time


but yeah, we're running clojure on the JVM on our backend, and get great leverage from the JVM ecosystem

Wes Hall13:02:49

Yeah, though perhaps unfair to place the blame purely at clojure's feet there. I spent rather a lot of my life building applications using spring + Java, and they were not fantastically quick to start either. Apps using larger, more complex libraries in general are a bit slow to get going, though, as you say, much better than they used to be. I think one fun thing to consider in all this is that the single threaded nature of JS systems is, in part, a solution to the same problem that persistent data structures solve (better). Multithreaded apps in pure JS which is heavily stateful idiomatically, would be a nightmare, but I am very comfortable writing multithreaded apps in clojure on the JVM because of the persistent data structure stuff. Threads are great if the state sharing problem is eliminated.

Wes Hall13:02:12

I'd say this, if you are writing cljs on node, make sure your core.async-fu is world class, because you are going to need it to be 😄

Wes Hall13:02:00

That's the 'general you', not anyone in particular.


@wesley.hall i eschew core.async... don't like it for non stream-oriented stuff

Wes Hall13:02:06

I tend to treat it like the low-level primitive that it is, and try to wrap any complicated stuff away in useful functions. Promise libraries already do this kind of thing of course.

Wes Hall13:02:55

That said, straight, ordinary, boring callbacks work fairly well in clojure land if you really must doing this single threaded stuff 🙂


promise-composition all the way here 🙂


with core.async / manifold-streams for stream-like things as appropriate

Wes Hall13:02:25

I'll confess that I haven't taken the appropriate time to really dive in to looking at manifold, but I probably should.


> promise-composition all the way here Do you mean clojure.core/promise or javscript promises @mccraigmccraig?


@rickmoynihan bluebird on cljs (via funcool/promesa) and manifold/deferred on clj


clojure.core/promise isn't composable, 'cos it doesn't support callbacks


it composes by blocking does it not?


@rickmoynihan ha, yeah, i guess you could say that 😬


so "`clojure.core/promise` isn't composable without blocking"


> but as a serverless execution engine for cljs node makes quite a lot of sense, given how long it takes a clj app to spin up 💯


although even then a pathological cold start for node (and thus cljs) could still be 6+ seconds


and again with a caveat that was few years ago: similar experience -> we ended up writing the Lambdas in Python


Tbh we saw similar variance with python. Node was faster on average if anything


I’ve tried using node-side CLJS on Lambda few years ago, but decided the libraries I need were not there yet

Wes Hall15:02:23

Really? 6 seconds? We did node + lambda stuff at my last gig and never saw start up times remotely like that.


Yeah so there's a few caveats with that


We had quite a big data set to look at, like tens of thousands if not 100k invocations in a day


So those were outside cases


But they happened more often than you'd think


As did multiple invocations actually


We had to be quite careful about deduping or upserting


The other probably most important factor is lambda pathological cases are much worse inside a VPC


For my side stuff I don't use VPCs


At work it was all multiple VPCs per account or project so it was a bit complex


Enterprise innit


mostly AWS SDK from what I remember


anyone know how to get the history of git commits which have touched an area of a file ?


well… intellij & co has a “show git history for selection”


looks like you can pass a line-number range to git log


nice that it lets you track a function too


I use git-timemachine in emacs


then run backwards and forwards with n and p


not quite the same but the rough area


:thumbsup: to git-timemachine


also the git pick axe is a nice trick git log -p -S <<THING>>


that is awesome and exactly what i need @rickmoynihan


yeah it’s pretty great


On the subject of git… does anyone know any tricks for effectively git-blaming conflicting patches during a merge or rebase?


Bookmarks. That's how you avoid having to remember lots of ports & stuff. You use a bookmark. picard-facepalm