It is no accident that famous JavaScript tools keep being rewritten into C++, Dart, Go and Rust.
EDIT: I wouldn't choose TypeScript either for this type of use case, but not for the reasons they state, that's my point
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.
Ocaml is more practical, and less punishing (you can do IO without monads), but the most important diffrence is performance. Haskell is VERY hard to make predictable because its lazy. Ocaml is strict so general system performance is much easier to predict.
But they are sibling languages in my book, while i still prefer ocaml over haskell.
A big part of interacting with APIs (which I imagine Stategraph does) is just dealing with records, and working with records in Haskell is really annoying unless you bring in lenses which bring a lot of complexity.
Even Haskell is not functional in the strictest sense. It has unsafe IO. It can throw exceptions. Functions may not halt.
My point was that without any escape hatches or magic you can code a segfault starting in ocaml5. That may be true of haskell? It is true of rust too, though the only known way to do it isn't something that is likely to happen by accident and is tracked as a bug. In ocaml5 if you use domain, it is down to experience skill, and some luck to be sure you used atomic when necessary. I'm a bad programmer despite going on four decades of experience. I'm not even remotely methodical. If I adopt ocaml for a project I'm using 4 or adding something that fails the pipeline if it finds domain anywhere.
It shouldn't, the OCaml 5 memory model bounds the reach of data races in both space and time. [1] Thread-unsafe code won't be correct when misused, but it will stay memory safe unless you reach for an additional escape hatch (or you find an implementation bug of course).
[1]: https://ocaml.org/manual/5.4/memorymodel.html
I'm much more concerned about the amount of poorly vetted escape hatches in wide use in OCaml, mainly for bindings.
A loop by itself is not non-fp, as i can do the exact same thing via recursion. Its just syntax.
Hell, i can write a never halting program in lambda calculus with a fixed point combinator causing "undefined behaviour".
OCaml as the discussion subject on this thread, allows for mutable data structures, and I am old enough to have been taught Lisp as one possible avenue for FP.
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?
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.
I know that isn't everyone's view, but I do hope posts like this, even if not technicaly deep, at least let people know that there are lots of options out there.
Occasionally I do still fight it, e.g. if you want a self-borrowing structure there still isn't a great solution (I think Rust should support position independent borrows) but overall it's fine.
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.
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.
Sum types enable much higher levels of expressivity of what valid states are while still being statically analyzable. Any new PL lacking them, IMO, is making a huge unforced error. They don't apply for every situation, but they do handle a large amount of day-to-day programming concerns.
Side note: OO is oft-maligned in OCaml, but I really appreciate that they included it anyway. I much prefer languages that give you a set of tools to use in whatever situation you find yourself in.
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 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 write OCaml myself, but not for $paid job, it's okay, it's a fine language although with cruft, but it's not the panacea described here.
It's one thing to pick a language that I like and am productive in, it's another to choose a language for a larger team.
If you've found an full team of motivated and capable OCaml coders, great.
How true is this in practice? I mean on the one hand sure Operation 2 doesn't seem some half modified state from Operation 1. On the other hand Operation 2 now has some stale state and makes the wrong decisions does the wrong thing because it didn't see Operation 1's changes.
cyberpunk•2h ago
So i work at an org with 1000s of terraform repos, we use the enterprise version which locks workspaces during runs etc.
everywhere else i’ve worked, we either just use some lock mechanism or only do applies from a specific branch and CI enforces they run one at a time.
My question is: who is this aimed at and what problem is it actually solving? Running terraform isn’t difficult - thousands of orgs handle it no problem - the issues I have with it with it have never been around lock contention and race conditions..
ab5tract•2h ago
sausagefeet•2h ago
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.
leoqa•2h ago
sausagefeet•1h ago
That depends. There are many organizations (we talk to them) which have plans and applies that take 5 - 10s of minutes, some even close to an hour. That's a problem. We talked to one customer that a dev can make a change in the morning and depending on the week might have to wait until the next day to get their plan, and then another day to apply it, assuming there are no issues.
If you're in that position you have two options:
1. Just accept it and wait. 2. Refactor your root module to independent root modules.
(2) is what a lot of people do, but it's not cheap, that's a whole project. It's also a workflow change.
Stategraph is trying to offer a third option: if your changes don't overlap, each dev can run independently with no contention.
Even if one doesn't think contention over state is a big deal, I hope that one can agree that a solution that just removes that contention at very little cost is worth considering.
internet_points•1h ago