Codeq comes to mind

But really Stu used to joke that doing a twitch stream of watching Rich code is him lying in a hammock for several days then typing out the final code. Which is, honestly, not that wrong. He does more work before typing a line of code than any programmer I've ever met, so the code is almost incidental at that point

https://github.com/richhickey/ has a few little repos as well, some interesting early work connecting clojure to amazons sdb and using rdf with clojure

which includes this line of code: :sustain [0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0]

which is somehow validating of some of the things I end up with.

@U0KTDCDJL what about Rich’s ant simulation?

At the risk of starting another flame war Don't use mount

please send the alternative via passenger pigeon using the cypher.

Carrier pigeon unavailable, please stand by for signal

https://github.com/stuartsierra/component

👍

Until we figure out pure effect handlers 🙂

The main issue with mount is it creates global, mutable contextual state Component is super explicit, straightforward and composable

just like the ingredients for bananas flambé.

How about integrant? Is there a guide or something to help you choose if you're not sure of the pros/cons of each? I mean I have a general idea but I don't feel comfortable recommending one or the other. I've heard that the cost of having configuration as data in integrant is some magic that can make it harder to reason about but I don't really understand why that's the case. As if that weren't enough, there was a thread recently here (don't remember which channel) where some people argued it's better to go with your own solution rather than use any of these libraries. edit: Sorry, not interested in a flame war either, I'm genuinely curious.

that's the reason I prefer component. 0 magic

+100 No Magic. Have the code do exactly what you want. Component is the only solution that satisfies that. Mount is global mutable state. Integrant is magical data.

There are some things where abstractions just aren't worth it.

Could you give an example of magical data? I don't think I understand the argument. Integrant is generally straightforward from what I've seen but maybe the systems I've worked on are not big/complex enough?

You said it "I've heard that the cost of having configuration as data in integrant is some magic"

My feeling is that the multimethods are spread all over the place and I find it very hard to figure out how Integrant-based code actually works (because finding all the parts is hard). I do not find this to be an issue with Component.

We’re using integrant, and I don’t find this to be a particularly big problem. Sure, it uses multimethods, with the caveats that usually applies, but we keep the number of integrant-things to the necessary minimum, and require all the relevant namespaces from the system spec. Works well enough.

Closeable-maps

https://github.com/piotr-yuxuan/closeable-map

I also use Integrant and find its "magic" relatively transparent, but I have read its implementation more than once. And keeping an eye on juxt/clip in the meantime.

+1 for integrant because it combines configuration with state management. That means I can have one application deployment using services that are provided by libraries - ie working as a monolith - but then switch at the configuration level and use an alternative version that uses the same service but implemented via an external microservice, potentially not even loading the namespaces of services not being used. And one doesn't need to make the data magical; one can use spec to validate and report back when configuration for a service is invalid.

We use this exact strategy to deploy our app, and parts of it as a service for a third party. It is very nice.

> but then switch at the configuration level and use an alternative version that uses the same service but implemented via an external microservice You can still achieve the same goal with component I think, you just have to map a configuration setting to a function yourself rather than depend on the tool to do it for you, right? Or is it more nuanced than that?

The nice thing about integrant is that the implementation is separated from the system description. So you describe the dependencies with data, and then start/stop each service using multi-methods.

So instead of a bunch of scattered ifs and buts, you can just build separate system maps and tell integrant to start them

I do like how integrant uses tagged literals to define dependencies but from what I understand I think you can get a similar behaviour with aero + component. I mean I'm not sure you need to have "scattered ifs and buts".

> If one wants to essentially build what might become microservices later I find Component/Integrant/... fairly orthogonal to this. (I'd still use those) For that 'eventual scalability' Polylith is at the right granularity. As its very name indicates, you start as a monolith, which later can become N things (there are problems that it doesn't solve and that are hard to solve generically anyway. e.g. how do services communicate - sync or async?)

[in regard to component vs integrant] I'm sure as with most things in tech, anything is possible. The other thing that really abstracts the what from the how is pathom - so this makes composing functionality so much easier - my systems are composed of pathom resolvers and mutations and that composition is defined by integrant (and aero) and would as easily work in a monolith or serviced by independent micoroservices.

The dependency map and configuration in component can be loaded as data and configured with aero. It results in a pretty clean solution

It's an often forgotten function, system-using, which essentially lets you provide your dependencies as data

Just out of interest, what do people do for turning these component descriptions into infrastructure descriptions? Does anyone have some code in their project build process that takes the dependency map and outputs some terraform or cloudformation or whatever? I ask because it's a thing I've done in a couple of projects now and wondered if anyone else thought this was useful... or is it just me?

I find more useful to manage the stratup without making "components" dependant on each other, and Closeable Maps just re-use something that already does the start/stop job that is java.lang.AutoCloseable

@U0X9N9ZK5. Without further understanding of your goals, to me it would seem a bit overkill to use microservices for the purposes of encapsulation and reasoning about a system? It seems Clojure Namespaces and Libraries also offer encapsulation without the downside of having to spin up microservices and communicate over network. Also, compared to library/namespaces, each microservice call has additional concerns: • Additional latency • Bandwidth limits • Serialisation • Deserialisation • Failure of network or remote machine • Timeouts • Retries Generally, I think Microservices are needed when: • Zero code sharing between services is needed or allowed. • Services need to be managed or owned or deployed independently • Services need to scale independently or require different hardware (e.g. some services require GPUs or lots of memory). • Services could compete for resources or conflict if they are together. • Services have conflicting library requirements (e.g. different versions of the same library). • Services have different stability (e.g. one service needs to be restarted frequently). • The developer wants to learn about microservices or experiment with them.

This is really helpful, and what you’re saying is my sense of what is right. So I need to work on my ‘library and namespace fu’. I think the problem is that I tend to end up pulling a library into a number of different places and forget of where they are (i.e. spaghetti code) where I am dreaming this can be mitigated with, say, microservices and kafka. But then I introduce new issues (and probably some of the same ones).

Look at the (source fnil) - function returned with (fnil + 0 0 0) has arity 2, 3 and 3+.

understood.

kind of a shame - given the backing function has arity 1+ it feels a little inconsistent.

probably dumb, but I don’t get why not add support for arity-1 to fnil? ie:

(defn fnil
  ([f x]
   (fn
     ([a] (f (if (nil? a) x a)))
     ([a b] (f (if (nil? a) x a) b))
     ([a b c] (f (if (nil? a) x a) b c))
     ([a b c & ds] (apply f (if (nil? a) x a) b c ds))))
  ([f x y]
   (fn
     ;; add this
     ([a] (f (if (nil? a) x a)))
     ([a b] (f (if (nil? a) x a) (if (nil? b) y b)))
     ([a b c] (f (if (nil? a) x a) (if (nil? b) y b) c))
     ([a b c & ds] (apply f (if (nil? a) x a) (if (nil? b) y b) c ds))))
  ([f x y z]
   (fn
     ;; add this
     ([a] (f (if (nil? a) x a)))
     ([a b] (f (if (nil? a) x a) (if (nil? b) y b)))
     ([a b c] (f (if (nil? a) x a) (if (nil? b) y b) (if (nil? c) z c)))
     ([a b c & ds] (apply f (if (nil? a) x a) (if (nil? b) y b) (if (nil? c) z c) ds)))))

.m2 caching can work very nicely when set up properly. Have you exhausted that option?

in our current setup we spin up a docker worker to build our artifact, so it's not the ideal but it is something I've looked at as an option

for additional context there's other artifacts we use (npm, ruby stuff, etc) that we probably are going to want to supply in this way as well, so it would be nicer to have a consistent approach

I've run both artifactory and nexus internally for this. Nexus is easier to get up and running. But you can also have a hosted artifactory pretty easily but I think you will need to pay them for it.

yeah a shared .m2 is a good way to proceed

even one per worker is not bad

if you are using gh actions it's quite easy to cache

I have also heard good things about reposilite

that's definitely food for thought, sadly we're not using gh actions so it's not as simple here, but if shared .m2 is a good way to proceed I'll have a look into that, running nexus on our network and reposilite which I hadn't heard of before now

thanks all!

reposilite in particular looks really cool

I didn't try it myself, but know people who did. It's quite young so there's that, I suspect nexus/archiva & co are more solid but also more complex for sure (I have experience with archiva)

yeah, one thing that stands out is that it looks like running as a docker container is more of a first class citizen than e.g. nexus/artifactory where it's retrofitted. With our current architecture, running a docker image on the network is exponentially easier than setting up anything else so definitely appealing

makes sense

if you're going to use npm in the future, it's worth using something that supports that because npm doesn't have a very good track record of providing immutable artifacts that support a repeatable build process ... which may or may not be something that's important to you 😉

I hadn't heard of reposilite either ... good find @U050SC7SV 👍

do you do any aot compilation? maybe make sure you don't have any potentially stale class files laying around

Hey, so very quickly someone is going to show this book https://blog.klipse.tech/java/2021/03/05/data-oriented-programming-in-java.html Its not my favorite book but it kinda does try to directly answer that question

The core problem with doing clojure design patterns in Java is that there is no way to be both typed and support code that does A -> A & B

so in clojure it is common to do

(defn parse-json-body [request]
  (assoc request :json-body (parse-json (:body request))))

the book basically goes in to how to do that with Map<Object, Object> - which is doable

the part of Clojure design that is easier to adopt is to have immutable aggregates and use persistent data structures

so that means using either the records language feature or Immutables the library to make immutable aggregates and libraries like vavr or pcollections to back them

then use sealed interfaces to represent "or" type stuff

sorry for the tiny messages, I need to actually "send" or I never get started and this is the result

It might be more helpful if its interactive - so if you have some example Java code I can work through different ways to approach it

No jar, we just copy compiled sources and library jars into a docker container, and run it with java

We use badigeon to output dependencies to a directory

Some details here: https://cjohansen.no/clojure-in-production-tools-deps/

uberjar in a Docker container, with a launcher script to pre load secrets from the secret store, set JVM flags etc

These look like cool approaches… do either of you use a docker repository or the like?

I like playing around a lot and creating quick setups so ready to deploy docker containers are appealing.

yeah, no way around it - all images are stored and pulled from ECR and deployed to ECS+Fargate

The alternative is something like Digital Ocean imaged droplets or Amazon images and so on but they are less universal and sometimes lead to costs to even store.

@U0JEFEZH6 right on that seems extra appealing, then.

Even for a partial hobby setup the time saved in deployment (since I tend to build and tear down prototype deployments frequently) offsets the infrastructural setup for a docker repo.

I may have a different view once I get through a full docker repo setup though, lol.

Maybe, if your setup is simple enough you can use GH's Docker repo for hosting and use docker compose on a single droplet

can work for small/POC/throwaway type of projects

I didn’t know they had one.

it's pretty neat as within a single repo you can have a CI pipeline (tests and building images) + storage of said images. Not sure about pricing tho

All this is basically what I’m after… quick POCs till one makes sense to run with, then deployment with some sort of monitoring and graceful restart (which I associate with typical Java application servers).

And single purpose docker images (i.e. microservices) but it’s been pointed out here that I should think more about namespacing and being smarter about my monoliths then relying on something really complicated to make up for my reasoning deficiencies.

Right, a single server deployment + Docker compose should give you most of that

But I’m definitely on the fence. The answer is probably ‘both’.

don't do microservices until you really have to

This is what everyone is telling me.

In fact, the book ‘Microservices With Clojure’ also suggests starting out with a monolith until you need microservices.

What about if a server falls over? How are you all notified? Does something automatically restart it?

We don't, ECS just creates a new node and starts again + we have metrics and logs automatically instrumenting our services. I haven't managed an EC2 instance in over 3 years now

Gotcha. I think I got turned off of Amazon at some point because of their growing complexity, but Digital Ocean lacks a lot of that.

It depends on your project, I'm working on a product that needs all of this stuff (and I'd still maintain that we have a relatively simple setup) - I wouldn't run it on DO, because it would actually be more complex to orchestrate all these containers, authentication, instrumentation and so on. Just like with microservices: do not use AWS until you have to (for sake of completeness - AWS has simpler deployment options like Elastic Beanstalk, Lambda, or app runner https://aws.amazon.com/apprunner/ - but you'll always have to deal with some degree of AWS' plumbing)

Yeah… I feel like I need to be somewhere between DO and AWS.

I was always drawn to OpenShift but it’s mainly hosted and very expensive.

sounds like you want this: https://www.digitalocean.com/products/app-platform

or http://fly.io or http://render.com

These are really helpful links.

Some days I want to just try out an idea which requires a DB, a front-end, and so on and I want to get to seeing it work in minutes, not hours. Biff, the web framework, has been wonderful for this.

Well, it’s more than a web framework, which is what makes it great.

But for whatever reason I can’t stop thinking of unnecessarily (in most my cases) complex setups.

just announced on the 8th: https://www.digitalocean.com/blog/announcing-digitalocean-uptime

Nice! I’ve been wanting to start making ‘interactive’ diagrams… i.e. creating nodes generates infrastructure elements. This is helpful.

Or, more simply, interacting with a GUI that allows one to create these diagrams would update a model on the backend.

Hmm, that reminds me of GraphViz interactive online editor.

I’ll take a look.

This is interesting, especially since I was using Mermaid just last week. 🙂 How does the DSL approach compare to something akin to a Hiccup-like markup approach?

Hiccup heavily uses plain (nested) vectors, while my approach uses function calls.

Sure, but have you compared the pros and cons of the approaches? I ask because I recently made a similar DSL for Sieve scripts, and realized that a Hiccup-like markup approach works better for dynamic generation of output scripts. So I was wondering if you had a similar/different experience with Mermaid's code.

Hmm.. that’s certainly a food for thought. One shortcoming of the functional call approach might be that it is more difficult to add new keywords to the DSL if the target language gets a new one: e.g. if there is a new HTML tag <foo> announced by the Web Consortium, no breaking change to the DSL can be made if there is no set of whitelisted keywords used for validation: just use :foo for it.

However, like I just mentioned, that kind of flexibility requires an additional mechanism to be built in to the rendering function (`html` in Hiccup’s case), whereas the function-call approach does not since the available set of functions are predefined. So, invalid tokens are naturally unavailable, therefore this kind of validation is given for free.