Fork me on GitHub
#clojure-uk
<
2019-02-08
>
keithmantell08:02:25

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

alexlynham08:02:41

Morning morning

alexlynham08:02:03

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

alexlynham08:02:33

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

mccraigmccraig08:02:43

@alex.lynham does compojure work on cljs too ?

mccraigmccraig08:02:20

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

mccraigmccraig08:02:02

but you didn't include #yada on your poll

4️⃣ 10
alexlynham08:02:55

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

agile_geek09:02:14

Bore da pawb! welsh_flag

maleghast10:02:16

Morning All

👋 10
alexlynham11:02:31

@dominicm that's a great post

❤️ 5
zyxmn11:02:02

Does anyone here use clojurescript for server side?

👂 5
otfrom12:02:14

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

mccraigmccraig12:02:26

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

zyxmn12:02:34

for me its clojurescript graphQL server 😮

Wes Hall12:02:38

cljs+node servers....

mccraigmccraig12:02:49

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.

mccraigmccraig12:02:33

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.

mccraigmccraig13:02:48

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 🙂.

mccraigmccraig13:02:16

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

mccraigmccraig13:02:17

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.

mccraigmccraig13:02:22

@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 🙂

mccraigmccraig13:02:37

promise-composition all the way here 🙂

mccraigmccraig13:02:54

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.

rickmoynihan13:02:41

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

mccraigmccraig13:02:25

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

mccraigmccraig13:02:45

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

rickmoynihan13:02:49

it composes by blocking does it not?

mccraigmccraig13:02:11

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

mccraigmccraig13:02:43

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

alexlynham14:02:08

> 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 💯

alexlynham14:02:28

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

Aleksander15:02:33

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

alexlynham09:02:04

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

Aleksander15:02:20

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.

alexlynham09:02:20

Yeah so there's a few caveats with that

alexlynham09:02:44

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

alexlynham09:02:53

So those were outside cases

alexlynham09:02:08

But they happened more often than you'd think

alexlynham09:02:17

As did multiple invocations actually

alexlynham09:02:43

We had to be quite careful about deduping or upserting

alexlynham09:02:33

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

alexlynham09:02:44

For my side stuff I don't use VPCs

alexlynham09:02:12

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

alexlynham09:02:16

Enterprise innit

Aleksander15:02:25

mostly AWS SDK from what I remember

mccraigmccraig16:02:45

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

3Jane16:02:02

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

mccraigmccraig16:02:32

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

3Jane16:02:27

nice that it lets you track a function too

danielneal16:02:13

I use git-timemachine in emacs

danielneal16:02:26

then run backwards and forwards with n and p

danielneal16:02:36

not quite the same but the rough area

rickmoynihan16:02:42

:thumbsup: to git-timemachine

rickmoynihan16:02:39

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

mccraigmccraig17:02:41

that is awesome and exactly what i need @rickmoynihan

rickmoynihan17:02:32

yeah it’s pretty great

rickmoynihan17:02:18

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

dominicm22:02:01

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