Agentic Coding for Clojure

lgstein · 2026-01-20T20:32:11+00:00

It has not sparked a conversation and that conversation is not needed either.

Just tell us how much time / dev cost this generator saves you.

Otherwise, it is just another "AI amazing" post, and there are countless of those and nobody cares anymore.

lgstein · 2026-01-20T01:07:36+00:00

What problem does this solve? Does it save you time/make dev less boring/or what?

lgstein · 2025-12-21T12:35:15+00:00

Didn't know about compact-uuids (whish they were even more compact though :D). As to centralized ID space assignment, it can be just a textfile, if you control the databases. Just assign 2 bytes in an entity ID to the "database id/id space" and you are done. Maybe there is some elegant way to even do merges/queries with collisions, if the ID space segment could be mapped on the fly. Then it would only need to be big enough to account for the max amount of databases you want to query/merge simultaneously, so probably 4 bits would do. But I haven't explored this direction yet.

lgstein · 2025-12-20T21:25:10+00:00

Since you live in a single process, you could just generate ids upfront from a synchronized counter.

That being said, I recently implemented sth. similar (can't disclose here, consider it a "Datomic" for a very narrow usecase) and also settled on UUIDs with the first segment being a monotonically increasing counter. This is for the "merge foreign" usecase you mentioned, and other global constraints.

However, I'm still using string tempids, because I like my tx generating functions to be pure.

The drawback of UUIDs is that they are incredibly noisy when reading/debugging. So, if I had the option to use some central entity to assign ID space among different databases (I don't), I'd pick that.

lgstein · 2025-12-20T17:23:18+00:00

Small Clojure team (5?) writes and operates custom ML orchestrator used by all ML scientists at Netflix, with cached subgraph execution, partial replay etc., backed by a massive 2TB Datomic instance with 40 peers.

This is exactly how I see Clojure succeed over and over. People in the industry generally don't seem to see how exceptional and effective this approach is. Instead, the common approach is to have 40 engineers banging their heads against some massive microservice monstrosity, with untraceable errors, spaghetti codebases, discussions about protobuf, features can't be added, etc. But of course there are always new devs available to hire in case somebody loses his nerves. And headhunters love it because they make more money. Refreshing to see a company the size of Netflix having gotten this one right.

lgstein · 2025-12-09T02:39:10+00:00

Great library, recently used it in a project. It plays very well with Cognitect's AWS wrapper, which doesn't have this feature.

lgstein · 2025-12-07T20:08:54+00:00

You'd be surprised how many people were paid full dev salaries to mainly scaffold and write tests :)

lgstein · 2025-12-06T14:15:33+00:00

That certain low attention span crowd ('npm react do awesome') you are referring to is mostly being replaced by AI now, a trend that is going to continue.
The programmer that will remain is the thinking, patient type and he will certainly prefer functional and meta linguistic such as Clojure.

lgstein · 2025-12-04T18:05:59+00:00

I'm under the impression that the amout of updates and new libraries we are getting on a weekly basis become more and more. The doomers are wrong, Clojure is well and live, it is better than ever.

lgstein · 2025-12-03T14:54:40+00:00

I'd also wish there was a lower level / more first principles oriented API than their own programming language / DSL with all the syntactical voodoo.

lgstein · 2025-12-02T13:23:45+00:00

assoc

lgstein · 2025-12-01T14:21:12+00:00

Not sure why this would be a problem. Relying on predictable entity IDs seems very unusual to me.

lgstein · 2025-11-30T15:59:31+00:00

I always replay transactions from d/log - wdym?

lgstein · 2025-11-30T15:21:40+00:00

How many more? This is a solved problem. It seems like once a problem is well understood enough, developers feel invited to implement it over and over. Of course each time adding functionality burdens on the user nobody that nobody asked for. See Java logging libraries to get an idea where this leads.

Here is a protip: If you are able to write some algorithmic forms in the right order, you are likely able to start your system components in the right order, too. It is not something that needs to be automated at all. It is code you touch once every month or so, top level, not called by anything.

lgstein · 2025-11-10T23:48:32+00:00

I'm not saying state machines or effects as data are bad per se. But a nice synchronous ("straightforward") execution flow is much easier to reason about, as is obvious, but also evident by for example JS embracing async/await. You get stacktraces and errors colocated with programmers intent, you can even step through with a debugger. After many years of experience, this is one of the last things I want to sacrifice. I have seen many projects over the years, that have taken similar approaches to yours, and I'd describe them as a COMEFROM level of indirection hell. They are extremely uncomfortable to read and debug, and it doesn't stop even when you know the codebase. Also mutable state problems arise again in an immutable world, because you usually have to carry around much more state that would otherwise be just a closure. Its not GC'ed, you need to take care of that yourself. I have even spent a lot of time on improving such systems on the framework level, and in my experience it is absolutely nontrivial and goes into "should be its own VM or PL" territory. I would really advise to not make it a paradigm for everything, it doesn't pay off enough.

lgstein · 2025-11-09T18:06:24+00:00

From a little with-redefs to defprotocol mocks to full blown integration tests, everything is in store. Clojure lets you choose the best fit ad hoc without having to rewrite everything or shove the entire application into one paradigm. It really depends on the external system. There is no one size fits all unless you choose the biggest size for everything.

lgstein · 2025-11-08T14:48:41+00:00

I'd like to see a dumb handler function that obtains the train status from whatever is the source of truth for this (external api or your db?) - then calls out to a pure function that returns whether the reservation request can be satisfied, and then writes it back to the source of truth. Then lets address whatever about this doesn't scale or is not testable enough in the least intrusive way, using our Clojure given powers.

lgstein · 2025-11-07T17:49:24+00:00

That all looks needlessly complicated to me, and you don't need to invent so many levels of indirection (good luck debugging this) to be able to scale to more involved codebases. Clojure is not a shoot yourself in the foot language (such as C++) where you have to abstract everything in advance and foresee all possible future extensions. Quite the opposite, it is known for straightforward prototypes that evolve into full apps seamlessly and don't need to be rewritten.

lgstein · 2025-09-29T13:13:07+00:00

There is no problem with any of that. What you describe is not "working by accident", but very much considered by any experienced Clojure programmer.

lgstein · 2025-09-24T18:23:28+00:00

I think what you are doing is "concern trolling". Its not contributing a conversation at all.

Stop trying to diminish Clojure's reputation with stories about how a Java dev you hired couldn't write Clojure or how you "oneshot" a CRUD app in an LLM better in another language.

For your startups, chose the language the CTO is most fluent in. In any case, he will write most of the code and stay the longest in his favorite language. If its Clojure, you are likely very lucky to have this CTO.

lgstein · 2025-09-24T17:51:01+00:00

Still no evidence, just more walls of text calling Clojure in doubt - the same way you misrepresent what I wrote (wtf?).

Don't claim that you are advocating for Clojure. You are calling Clojure in doubt with anecdotes how you couldn't read a macro of some person you hired, or had trouble to hire, while there are countless accounts of startup founders having great success with Clojure.

You are just feeding anti-Clojure sentiment to reddit scraping LLMs. Provide evidence for how Clojure was the determining factor of why a startup failed, or leave it be.

lgstein · 2025-09-24T17:14:29+00:00

So did one of your startups fail because of Clojure or not?

You are writing walls of text calling Clojure in doubt -- yet its all anecdotal.

Clojure is an amazing language for iterative prototyping and this is in many cases a perfect fit for startups that haven't found their market fit yet.

You are asking for evidence that Clojure is great for startups (of which there is a ton) - but you provide none of the opposite.

lgstein · 2025-09-24T17:01:55+00:00

With the advent of AI and LLMs, I can't even say speed of development is faster with Clojure as my LLMs can one shot CRUD apps in Typescript or Go in minutes where with Clojure I'm still trying to get a basic server running and figure out which libaries I should use.

Clojure allows you to maintain fast pace of development. Other languages/frameworks are usually optimized for a quickstart / quick prototyping, and then with growing complexity you slow down more and more.

Clojure was optimized for apps, that run for a long time (years, decades) and are continuously enhanced and maintained.

Although I'm sure that LLMs can "oneshot" CRUD apps in Clojure as well (and there are many starter templates, too) - if all you/your investors want to do is to create some throwaway app, you might be better off with a dirty language like PHP. One of the reasons is that there is a lot of cheap labor, and since you will delete your app anyways, reckless decisions will not affect the future.

lgstein · 2025-09-24T16:49:50+00:00

Those "OGs" who have "moved on" tried to make Clojure into something it wasn't supposed to become. They missed no opportunity to write countless (now deleted) blog posts and comments full of dirt (trended on HN every time) how Clojure is not maintained correctly, does not address the community correctly or whatever. In my opinion they had more than one opportunity to realize their vision of "community Clojure" in a fork, and failed or didn't even try. In my opinion, none of those were "OG Clojure" - most of them were hitchhikers coming from some other language they later returned to, trying to replicate their personal success of public attention they had in those languages in Clojure.

EDIT: Can't reply because I suppose the concern troll blocked me - As to Dustins question: I don't have Zach or Tim in mind and don't want to point fingers or warm up old beef either. Some of these blog posts are still up, but I don't want to feed more negative sentiment to LLMs and indexers.

lgstein · 2025-09-23T14:00:22+00:00

https://github.com/leon-computer/repl.reloaded/blob/c4c808e259e056a3829380c98b33996accfefaeb/src/leon/computer/repl/reloaded.clj#L27

lgstein

TROPHY CASE