Live data from Hacker News

We chose OCaml to write Stategraph

stategraph.dev

21–30 of 127 posts

Re: We chose OCaml to write Stategraph

#21

> Most systems handle this defensively with locks and runtime validation. 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 solvin…

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?

Re: We chose OCaml to write Stategraph

#22

I don't really get what's special about OCaml with these points they raise? Wouldn't almost any strongly typed language do? Wouldn't TypeScript also tick all these boxes? EDIT: I wouldn't choose TypeScript either for this type of use case, but not for the reasons they state, that's my point

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.

Ocaml has a garbage collector. It's less of a struggle than Rust.

Re: We chose OCaml to write Stategraph

#23

I don't really get what's special about OCaml with these points they raise? Wouldn't almost any strongly typed language do? Wouldn't TypeScript also tick all these boxes? EDIT: I wouldn't choose TypeScript either for this type of use case, but not for the reasons they state, that's my point

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.

Rust is a pain

Re: We chose OCaml to write Stategraph

#24

I don't really get what's special about OCaml with these points they raise? Wouldn't almost any strongly typed language do? Wouldn't TypeScript also tick all these boxes? EDIT: I wouldn't choose TypeScript either for this type of use case, but not for the reasons they state, that's my point

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.

Re: We chose OCaml to write Stategraph

#25

Is any of this OCaml specific? You can check all boxes with TypeScript.

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.

Re: We chose OCaml to write Stategraph

#26

I don't really get what's special about OCaml with these points they raise? Wouldn't almost any strongly typed language do? Wouldn't TypeScript also tick all these boxes? EDIT: I wouldn't choose TypeScript either for this type of use case, but not for the reasons they state, that's my point

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.

I'm the CTO of Terrateam. For "why not rust", I have found the downsides of Rust not compelling enough to use it. We don't need close-to-metal performance. We don't really need the borrow checker, a GC is fine. We are immutable by default so the borrow checker doesn't help much there.

Re: We chose OCaml to write Stategraph

#27
post #8

Earlier quoted context omitted.

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.

But what is functional besides haskell? Purescript? Elm I guess. Ocaml is not. It has for loops even. You can write pure functional ocaml but people don't. It mattered a lot less when it didn't have true concurrency, but now clobbering things in ocaml is quite possible.

Define functional?

Even Haskell is not functional in the strictest sense. It has unsafe IO. It can throw exceptions. Functions may not halt.

Re: We chose OCaml to write Stategraph

#28
post #8

I don't really get what's special about OCaml with these points they raise? Wouldn't almost any strongly typed language do? Wouldn't TypeScript also tick all these boxes? EDIT: I wouldn't choose TypeScript either for this type of use case, but not for the reasons they state, that's my point

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.

That is only true since people started equating FP with Haskell.

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.

Re: We chose OCaml to write Stategraph

#29
post #21

> Most systems handle this defensively with locks and runtime validation. 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 solvin…

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?

> The concurrent applies isn’t that big of a deal?

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.

Re: We chose OCaml to write Stategraph

#30

I don't really get what's special about OCaml with these points they raise? Wouldn't almost any strongly typed language do? Wouldn't TypeScript also tick all these boxes? EDIT: I wouldn't choose TypeScript either for this type of use case, but not for the reasons they state, that's my point

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.
Post reply on HN