Clojurians Log v2

Good morning

morning

mogge

👋

Morning

måning

Morning!

Morn'

imagine a lot of it will be if you need to interop with node libs basically (which you will for anything nontrivial)

True, but there is a question of how much of that will end up being necessary? I mean some of the compiled examples are quite impressive... http://teavm.org/gallery.html For example Invaders appears to be a 3d space invaders game with pretty nice looking graphics...

yeah, i just mean that IRL few/none of us are making games but we prob want node libs :) but then i'm biased, the JVM is more painful to me than node

even if i prefer JVM clj, i find the JVM insanely painful to work with compared to node

That's fair, I tend to think of them as having different tradeoffs, on the one hand the jvm clj side leaks a bit more stuff that I'd like when I'm doing interop and not in a good way, because most java things you get back are pretty opaque vs js. The js repl side is always really fiddly to get working correctly and I can't count the number of times where getting a nice build / dev env working in cljs is just frustrating. However once it all works, it's a lot easier to just get productive in... Assuming you don't try and change something in the environment, say trying to work in a lambda in my case, then it's lots of fiddling trying to get the build working again...

mmm i don't really use teh repl in cljs which makes me sad :(

also pervasive async etc just imo makes a repl semi useless cos i can't deref at will like i can on jvm

@alex.lynham (fn [v] (.then v pr))

There are ways I've gotten a nice repl experience working in cljs, but as I said, really fragile and only works on a project by project basis >_<...

better (fn [v] (let [r (atom nil)] (.handle v (fn [succ err] (reset! r (or err succ)))) r))

i know i know craig, but you know what i mean... it feels harder

and you know me, i'm a hippie and how a language feels when i write it is probably the most important thing

then again i guess my current project is structured as nano services that can be called as if they are regular functions

getting it set up is harder for sure, once it's actually going it's no longer harder, especially with a node-repl

so that's probably why i'm happy to just write unit tests

in a larger codebase that wasn't lots of 40 line services, i'd probably be sobbing, begging for a repl

tbf, shadow makes pain much lower these days

I find the browser repl in cljs works quite well these days; cljs tooling definitely isn’t quite as strong as on the clj side, so some cider middlewares etc don’t work. Also cljs isn’t as polished as clojure, and has some more edge cases associated with it. I’m not sure the pervasive async is a problem I’ve had much though. Most functions are pure and just working on a reagent state atom etc. You can drive the state/atom at the REPL and have the views update, or just eval the pure functions in your editor buffer etc.

ah, i'm working on node/serverless fns generally so browser repl can't help me :( then again i am getting stung daily by no runtime typechecking in typescript, argh

I find the JVM is very straightforward to work with… other than clj startup time etc, I don’t really have many problems with it… I certainly find node more problematic.

it is stable, that is true

but at the same time running hundreds of db tests in seconds on node from a cold start makes the jvm look tired and old

or, i should say, makes it feel that way at least

right up until the moment when you need to do tens of thousands of db ops per second on prod 😬

ah yeah, we'd horizontally scale the lambdas themselves, luckily we're a regular http app, not a stream/websockets situation 👀

i mean if i was doing stream data i'd be back to jvm clj in a shot

The JVM or clojure on the JVM?

ha, i don't think i'm being fair... i suspect our routing would run just fine on node (given a suitable kafka-streams equivalent), although the raw compute of producing effects would be slower than on a warm jvm

yeah probably true

outside of a VPC, with a well-packaged lambda your cold start would be pretty low, but probably still pretty large compared to the latency you're used to

since our front end is PWA-like and partially statically built, we could get away with a pretty bad pathological case before it became an issue

clojure on the jvm, not done much else on it besides a bit o' scala

but it's the jvm cold start and whatnot that eats up that initial time

compiling all our typescript takes milliseconds

Well not so much these days… JVM startup time isn’t actually that much these days, it’s about 200ms for hello world; which is gonna be an order of magnitude worse than node, but not a big deal in dev. It’ll not have warmed up either, so may still be noticeably a bit slower; but likely not that significant in most dev workflows, unless you’re stopping and starting the vm a lot. It’s really clojure that is slow to start, as it needs to load and compile namespaces and initialise vars etc.

Tricks like this can make a significant difference though: https://clojure.org/guides/dev_startup_time

Hmm, not seen that, ok, that's super interesting. Will have to see how much of a difference that makes!

I wouldn’t go so far as to say it makes these usages quick… but it does make them a lot quicker, at the cost of some complexity

yeah that makes sense

first Dustin Diamond and now Sir Thomas Moore 😢

@mccraigmccraig right up until the moment when you need to do tens of thousands of db ops per second on prod << Spoken like a true Cassandra survivor ! lol

@jasonbell i am on the verge of being able to outsource all our cassandra ops... i am confident it will feel very good

It's ironic it's called Cassandra because everyone believes it will cause misfortune

ha, well i've been using it for a while, and i'm still a fan

Something to test 😃...