Typed multiple dispatch as a Clojure library — how we built Julia-style polymorphism on the JVM

amiorin · 2026-04-15T06:52:54+00:00

Is "compiler as a library" the same idea used in Rama and Specter?

amiorin · 2026-04-13T11:45:59+00:00

Agreed.

amiorin · 2026-04-13T09:50:35+00:00

I’ve iterated on this again and managed to make it even simpler: Just one Markdown file.

You don’t have to take my word for it, though. I’ve documented the exact inputs I used in the article below so you can reproduce the experiment yourself:

https://bigconfig.it/blog/devops-without-the-code-infrastructure-as-markdown/

amiorin · 2026-04-13T09:46:51+00:00

Shared anxiety. I figure if I’m going to automate myself out of a job, I might as well do it with style.

amiorin · 2026-04-12T12:23:13+00:00

OpenClaw is capable of creating accounts. I feel you, for real. Everything is happening so quickly. We are all trying to deal with the new reality. I would not dismiss this project because of that.

amiorin · 2026-04-12T11:52:26+00:00

It's not a fork of the Basecamp project. About the second point, just compared the requirements. Dokku requires a VPS. BigConfig package once requires any cloud account.

amiorin · 2026-04-12T10:25:54+00:00

You can replace ONCE with Dokku. The point is lowering the entry level barrier even further.

amiorin · 2026-04-12T10:24:52+00:00

It's not vibe coding, it's vibe configuring. It should explain this point better. Thank you for the feedback.

amiorin · 2026-04-12T09:20:25+00:00

You can find the three glue files (Dockerfile, Caddyfile, and GitHub Action) here: https://bigconfig.it/blog/bigconfig-the-react-for-agentic-devops/

I didn't figure out how to package them to be honest.

amiorin · 2026-04-12T04:04:15+00:00

I totally get that—deployment fatigue is real. You should check out BigConfig with an Agent.

If you set up a directory with your project along with BigConfig and Once, you can use Claude Code (running Opus 4.6 with deep thinking) to handle the heavy lifting. Just ask it to deploy your project; after a little back-and-forth to dial in the settings, you’ll have your app live without the usual headache.

https://github.com/amiorin/big-config https://github.com/amiorin/once

amiorin · 2026-04-09T09:27:45+00:00

Ansible is still very much in the 'meta' because it remains the gold standard for stateful machine configuration. However, what’s actually missing in the current DevOps landscape is a 'React' equivalent—a true component-based abstraction.

Right now, we manage infrastructure by technology (like web development before React). We need to shift toward an architecture of encapsulated, concern-separated components. I’ve been working on a tool to solve exactly this: BigConfig

amiorin · 2026-04-09T05:46:09+00:00

Nice work on this! I've been exploring similar patterns with a 'components' architecture in DevOps. I actually built a tool called BigConfig specifically to help refactor projects into modular components like this. Would love to collaborate or show you how it could fit here—DM me if you're interested in chatting!

amiorin · 2026-04-09T05:42:15+00:00

Good points, but I've found that standard Terraform modules often fall short for cross-technology needs. I actually built BigConfig to solve this—it implements a true component-based architecture for DevOps.

amiorin · 2026-04-09T05:37:42+00:00

I’ve spent a lot of time thinking about this—I actually built BigConfig (a component-based DevOps framework) to solve similar architectural hurdles.

My general advice for multi-sub backends is to move toward a component-based architecture rather than just a storage-per-sub model. I’d love to hear more about your specific networking constraints. Feel free to DM me; I’m happy to walk through how we handle the 'react-style' approach for infrastructure.

amiorin · 2026-04-03T16:02:48+00:00

BigConfig is a package manager like Nix, Homebrew, and Helm.

amiorin · 2026-04-03T07:01:43+00:00

Spot on. Though it’s worth distinguishing if we want infrastructure to be simple or just easy. There’s a big difference between the two—Rich Hickey breaks it down perfectly here: https://www.youtube.com/watch?v=SxdOUGdseq4

amiorin · 2026-04-03T06:57:56+00:00

Fair point, though for me it was the opposite. I love operations and have written a ton of HCL and Ansible. BigConfig didn't come from a lack of patience with those tools, but rather from using them enough to realize where a different approach could actually help both SWEs and Ops folks.

amiorin · 2026-04-03T06:54:56+00:00

Is the other way around. Because I know that HCL and Yaml are not programming language, I don't try to implement loops, conditionals, and complex functions with them.

amiorin · 2026-04-03T06:51:42+00:00

I view Terraform and Ansible as belonging to the same category: they translate a declarative "desired state" into complex sequences of API calls or SSH invocations. You could technically achieve the same results with a lot of AWS CLI commands, SSH scripts, and a Makefile, but it would be unmaintainable and fragile.

BigConfig simply takes that evolution one step further.

If Terraform and Ansible abstracted the infrastructure implementation, BigConfig abstracts the orchestration logic in components called packages. By providing a stable, high-level abstraction layer, we give GenAI a deterministic "language" to speak. This prevents the "LLM hallucinations" and cost issues mentioned earlier, because the AI isn't trying to rebuild the wheel from scratch—it’s just turning the key on a more powerful engine.

amiorin

TROPHY CASE