I have taken to using the Cider undef function when changing things like protocols, which seems to work reasonably well. Not that I have to do so very often. 😅

I ripped an inlined potemkin defprotocol+ out of rewrite-clj a long while back. https://github.com/clj-commons/potemkin/pull/69/files. Maybe it would help?

Looking forward to hear more about your experiences with Neovim 🙂 I use it daily for ad hoc text editing, but never for Clojure editing.

I'm still a noob, and would probably be more productive with Cursive ... but just the thought of being able to spin it up on a remote machine makes me happy 😄 Not sure if I'd ever need it ...

hehe

Well, vim, in itself, is pretty awesome imo. Looking forward to trade tips!

And I enjoy the familiarity of vim on whatever machine my fingers are connected to 🙂

I have a quite enjoyable setup with neovim and Clojure. You can take a look at my config here if you like: https://github.com/mdiin/dot-files/tree/main/nvim I’m using Doom Emacs for everything these days, but keep my vim config around for when I inevitably make an editor jump again. 😆

Cheers 🙂

That's unusual. I'm guessing your use case for ClojureScript is a bit different from most? i.e. not making React-based websites.

That's what I do mostly. And react native mobile apps. I like to be in control of what is re-evaluated. So my files remain unsaved for quite long periods of time, and then at some criteria (unknown to me which) I decide it is fine and I go and save the files and let hotreload do its thing.

as @U04V15CAJ points out, some things can cause difficulties when reloaded (if you reload a protocol definition then any extensions of that protocol which don't also get reloaded will no longer satisfy the protocol, unless you do metadata-based protocol extension), but as long as you follow the convention of putting your protocol defs in their own namespace then you only encounter this issue when you change the protocol, and as long as you have an approach which (tears down where necessary and) recreates the objects extending protocols after the reload then you are good

how many kloc clj source are you reloading this way? the initial reload starts with the full class path, right?

about 250kloc for the full reload

to me personally it's just not worth the complexity budget, I've given it a fair try

how long does the full reload take?

-curious-

hold on @U0509NKGK, i'll see

we're at 150kloc right now and full reload feels punitive 😅

we used to do the reload thing for a long time, but feel out of it. pondering giving it a fresh try

it would definitely be too slow if a full reload was needed very often ...

@U0509NKGK from a cold REPL start, reload to an active service: 41s given an already active service, reload without any code changes (i.e. destroy objects -> reload nothing -> recreate objects): 1.2s regular development flow reloads are usually a few seconds

ok that's not completely terrible 😄

the certainty that code got cleanly reloaded and all you had to do is press a button to get that, is worth some waiting

i generally only pay the full 41s tax once a day or so, the "few seconds" tax more often - maybe a couple of times an hour - and mostly just the almost instantaneous compile+reload ns tax

in order to make it work well i think you need to have a fairly principled no-global-state approach and to use something like integrant which can reliably manage setup and teardown of your app context

yep

welp we can't use reload cos we have clerk notebooks on the classpath 😅

we can configure c.t.n.r to not reload those namespaces

TIL about clerk 😁

> we can configure c.t.n.r to not reload those namespaces yes please!

@U0524B4UW #C035GRLJEP8 😄

does it live up to the documentation hype @U050CJW4Q? i.e. reliable, straightforwardly elastic, data-intensive app backends, stream re-use &c ... any common pitfalls or poor-fit use-cases ?

I would say in general yes. If you think of it as a fancy interface on top of rocksdb that is kafka aware. And if the provided abstractions don’t fit exactly you can use custom processors and use rocksdb directly from there. Common pitfalls would be related to partitions and keys. Certain operations required the partition keys to be the same (e.g. joins), so you need to be careful about repartitioning if it’s not handled automatically (like when using a custom processor)

i think i see - so, if e.g. i wanted to add an email to a user record, but with a constraint: only if there is no other user in the same tenant with that email, i would need something like: a KStream of commands: {:key [<tenant-id>,<email>] :value [:users/add-email-cmd [<tenant-id> <user-id>]]} joined to a KTable of: {:key [<tenant-id>,<email>] :value {:id <user-id> ...}} and a ValueJointer emitting values something like UserChange|Error

so data constraints have an effect on stream topologies ?

The keys have to match for the joins as a stream to ktable join essentially looks up the stream message key in the ktable’s rockdb kv store each time. Of course you can add your own constraints once in the valuejoiner fn. If you have more complex indexing requirments you can create additional state stores and look them up yourself

thanks @U050CJW4Q!