This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-08
Channels
- # announcements (2)
- # aws (1)
- # beginners (134)
- # calva (26)
- # cider (48)
- # cljdoc (41)
- # cljs-dev (12)
- # clojure (178)
- # clojure-brasil (1)
- # clojure-europe (16)
- # clojure-italy (30)
- # clojure-nl (13)
- # clojure-spec (118)
- # clojure-uk (81)
- # clojurescript (209)
- # community-development (77)
- # cursive (7)
- # datomic (23)
- # duct (6)
- # emacs (15)
- # events (2)
- # figwheel (13)
- # figwheel-main (18)
- # fulcro (4)
- # jackdaw (4)
- # jobs (6)
- # jobs-discuss (6)
- # kaocha (2)
- # lein-figwheel (3)
- # off-topic (4)
- # other-languages (22)
- # pathom (2)
- # pedestal (9)
- # perun (10)
- # portkey (1)
- # re-frame (41)
- # reagent (6)
- # reitit (4)
- # remote-jobs (1)
- # ring-swagger (6)
- # rum (5)
- # shadow-cljs (300)
- # sql (3)
- # test-check (6)
- # testing (7)
- # vim (1)
- # yada (9)
måning
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)
No I guess you'd write your backend using it and then use secretary or what have you in your cljs
https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to this article is far deeper than the title would have you believe.
Bore da pawb!
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 ?
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
@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 😬
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
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
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.
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 😄
@wesley.hall i eschew core.async... don't like it for non stream-oriented stuff
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.
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
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
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 ?
looks like you can pass a line-number range to git log
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?