We chose OCaml to write Stategraph

Definitely agree. Most teams don't choose a language for purely rational reasons, and we're not pretending we did.

We like OCaml, it makes us excited to build. We know the language deeply, which means we can reason about performance and behavior before we run the code. We can onboard new engineers quickly because the type system forces clarity.

The runtime is simple enough that we can predict what it's doing. So yes, part of it is that OCaml feels good to use. But that feeling comes from years of watching it make complex systems simpler to reason about, not harder.

> I think we should normalize saying that tech stack choices are subjective and preference-based. We're not robots. The social and aesthetic parts of a stack matter to people

I would just like to distinguish "subjective and preference-based" from "social and aesthetic" and also clarify some notions.

1. The social is objective. We are social animals. It is essential to what it means to be human. We need social relations to grow and develop and to become more human.

2. The aesthetic is objective. We confuse taste with beauty, and this is perhaps the legacy of influence of certain philosophical traditions on our thinking. Beauty has to do with the fullness with which some thing instantiates a form and realizes some end/good. So, when it comes to artifacts like programming languages, a beautiful language will satisfy some human purpose more perfectly than a less beautiful language. Taste is a matter of subjective disposition to beauty. Someone with bad or poor taste might prefer the inferior over the superior, for example, or fail to discern between the two.

We sort of create mystery about preference here, as if they were just arbitrary, immutable, inexplicable brute facts. But preferences can be more good or less good or even bad. Note the relation between preference and taste.

> We're not robots.

3. Typically - and I do not accuse you of this - this is meant to mean that what makes us human compared to robots is that we have emotions. But it isn't that. Many animals have emotions. What makes us distinct as human beings is the intellectual and the rational, which robots (as computational instruments) are not.

4. Post hoc rationalizations may not stand behind the actual motivations, but the content of the rationalization may remain true and valid nonetheless.

I think that in some cases where OCaml was chosen, like Docker or some parsers, the choice was obviously not evangelical. But I agree that in most cases it is a post-facto justification.

The first comments here are people reading this as if the authors are saying only OCaml can do this. They aren't.

Using something you enjoy is fine, as long as you don’t forget the person who is going to maintain your code after you move on.

This is pretty much obvious for people migrated from JavaScript to TypeScript and suddenly realised that most of their unit tests can now go to a trash bin.

Typescript (javascript) is kind of a joke compared to what ocaml brings to the table.

Ocaml has a top in class typesystem, a "faster than Go" compiler and (in 2025) good tooling. It allows you to say fuck it and write a while loop if you need to. Hell you can even do OOP. Also it has an incredible module system and full type inference. It also has an effect system, and good concurrency features (ocaml 5).

I cant say many other languages that has all the same features.

It's the combination with concurrency that makes this a hard problem.

And OCaml excels at solving that sort of problem. OCaml and Erlang are the only two languages that I'm aware of that have a really clean way of doing this, in most other languages there is always some kind of kludge or hack to make it work and at best you're going to do something probabilistic: it seems to work, even under load, so it probably is good now. Until six weeks later on an idle Tuesday the system deadlocks and you have no idea how it happened.

Besides the better type system, OCaml is a compiled language, you don't need workarounds like rewriting code in Rust and Go, as it happens on TypeScript/JavaScript world.

Certainly there are specifics between the type systems that differentiate. TypeScript generally chooses to enforce types in an ergonomic way whereas OCaml chooses to enforce types in a sound way. Whether or not that is a meaningful differentiator for someone is up to them.

This blog post shows the elements of OCaml that motivate us to use it. Is it complete? No. Maybe it should be more explicit that we like using OCaml, and these technical aspects aren't unique but certainly benefits we see.

Functional programming is immutable by default. TypeScript and many other typed languages don't really stop you from clobbering things, particularly with concurrency. Rust does. But immutability with GC is a lot easier to use than Rust if you don't need the performance of Rust.

• Stategraph manages Terraform state, so correctness isn't optional

TypeScript has soundness issues that OCaml does not have

• Strongly-typed data structures catch field errors at compile time

TypeScript does have this, although the guarantees are in practice weaker since libraries may have incorrect type definitions

• Type-safe SQL queries prevent schema drift before deployment

There are TypeScript libraries that offer this, so fair point!

• Immutability by default eliminates race conditions

TypeScript is not immutable by default

• PPX generates correct JSON serialization automatically

TypeScript does not have an equivalent to PPX infrastructure AFAIK. If there is, it's definitely not as widely used within the ecosystem compared to PPX for OCaml.

Edit: Downvoters care to respond?

OCaml has a much stronger type system than Typescript.

The real question is "why not Rust?". I've used both a fair bit and OCaml's only major advantage IMO is compile time. That doesn't seem compelling enough to put up with the downsides to me.

Hello, CTO of Terrateam here, the creators of Stategraph.

As you said, the common practice is to use locks on state to guarantee that operations don't step on each other. This works, however the cost is that if it takes 5 minutes to perform an operation, only one person can be doing an operation at a time, so if 5 devs are modifying infrastructure, the last one has to wait 25 minutes just to get back the plan, even if those 5 people are not changing overlapping resources in the state.

The way that most people deal with this is they take their infrastructure and break it up across multiple root modules, and then when those root modules, break it up again, etc.

Stategraph is solving the problem of getting all of the performance benefits of breaking up your root modules without breaking up your root modules. It dynamically determines which resources each of those 5 devs are operation on and, if the resources do not overlap, can run them in parallel.

That means Stategraph is manipulating state in a bit more sophisticated way than standard Terraform/Tofu, and we need to be careful we don't get it wrong.

Back in the day, before git, we had RCS. Developers would just lock files when they worked on them, and then unlock when they were done. Or you'd copy a folder manually ("branch") to work on things concurrently and then punch them in the shoulder when they forgot to unlock master so that you could lock it and check in. It worked absolutely fine, there were loads of workarounds!

Yeah I get the sense that terraform change application is solved by just serializing all changes? The concurrent applies isn’t that big of a deal?

Agreed and well said!

Those two type systems are not the same. Typescript has some soundness issues in the type system. They are there because they have to work seamless with javascript so it's understandable. And they improve many codebases that would have been otherwise written in javascript. But they do not in any way give you the same level of guarantees that OCaml, Haskell, or Rust would give you.

Does TypeScript emit machine code? OCaml gives you this option, if you need it.