Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We chose OCaml to write Stategraph

stategraph.dev

Post reply on HN
Print view View original

121–127 of 127 posts

Re: We chose OCaml to write Stategraph

#121

Post by sausagefeet »

pjd7 wrote: post #104
sausagefeet wrote: post #18

Earlier quoted context omitted.

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 i…

I'm not sure I would want this even if I could have it TBH. Engingeering org size is about ~200 with infra/sre/ops around ~25. Different teams want to move at difference cadences. At a certain scale splitting up things feels a little more natural (maybe I am stockholmed by prior limitations with TF though or just used to this way of operating now). But even then, we're moving to k8s operators to orchestrate a bunch o…

The way I look at it is that TF has a limitation on state size. And when you hit that limit, you have to either slow down a ton or do a (big) refactoring.

As comparison, if a programming language forced you to split your software into multiple executables when you got to a certain number of functions, I think, almost universally, we would say that it's not a production language. That is a stupid limitation and forcing development work on users because of stupid limitations is disqualifying.

But for TF, even if we are refactoring it because the tool is doing it, we tell ourselves that it's a good idea anyways because of good software practices. But splitting infrastructure over multiple root modules is, in my analogy, the same as being forced to do it over multiple executables. It comes with a lot of unnecessary limitations.

With Stategraph, you can choose to split your infrastructure over multiple root modules, if that is what you want to do, not because you don't have a choice.

V1 of Stategraph is a drop-in TF/Tofu replacement, but once it's there, you can see a path to something more like k8s operators, without having to do any migration of infrastructure.

Re: We chose OCaml to write Stategraph

#122

Post by pjmlp »

nrlucas wrote: post #120
pjmlp wrote: post #28

Earlier quoted context omitted.

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.

They have mutability, but it's generally not encouraged. The default is immutability.

It is available, that is all that matters.

Re: We chose OCaml to write Stategraph

#123

Post by abathologist »

Quekid5 wrote: post #106
abathologist wrote: post #98

Earlier quoted context omitted.

One of OCaml's outstanding, but too little mentioned, virtues is the community's commitment to extremely strong backwards compatibility guarantees.

Which led to a really bad standard library with next to no features... but yes, it's very stable. And, hey, if it works for you, that's great... but Batteries Included can also be great for a language.

Backward compat has nothing to do with the size of the stdlib, AFAIK. It seems you want to pick on a different part of the language ecosystem.

It's true this a matter of taste, but also worth noting that the OCaml compiler devs have made it very clear they are open to well-motivated extensions of the stdlib, and it has been growing at a decent clip in the last few years.

Re: We chose OCaml to write Stategraph

#124

Post by internet_points »

yodsanklai wrote: post #78
internet_points wrote: post #43

Earlier quoted context omitted.

What advantage does OCaml have over Haskell here? I find software transactional memory in Haskell so simple to work with that I have lost all fear of concurrency, but what am I missing out on?

I personally find OCaml more pragmatic than Haskell. Haskell has a steeper learning curve IMHO: monads are pervasive and are hard to understand, laziness isn't a common programming pattern and it adds complexity. I find type classes confusing as well, it's not always clear where things are defined. I like that OCaml is close to the hardware, there are no complex abstractions. The module system makes it easy to progra…

I should have specified. I wasn't asking about OCaml vs Haskell in general[0], but what advantage does OCaml have with respect to concurrency?

[0] I think most people just end up post-rationalizing whatever choice they have already invested in, I know I do :) With that in mind, maybe I as a mainly-Haskell dev should instead list some things I miss from OCaml: faster compile times, non-recursive `let` by default, polymorphic variants, labeled arguments

Re: We chose OCaml to write Stategraph

#125

Post by myaccountonhn »

phplovesong wrote: post #74
myaccountonhn wrote: post #71

Earlier quoted context omitted.

Also IMO the dev tooling is better for OCaml. Far better compile times. 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.

Tooling was kind of bad previously. But dune has got really good. I like the new dune developer preview thing that is still in beta. https://preview.dune.build/

Wow that looks slick!

Re: We chose OCaml to write Stategraph

#126

Post by Quekid5 »

abathologist wrote: post #123
Quekid5 wrote: post #106

Earlier quoted context omitted.

Which led to a really bad standard library with next to no features... but yes, it's very stable. And, hey, if it works for you, that's great... but Batteries Included can also be great for a language.

Backward compat has nothing to do with the size of the stdlib, AFAIK. It seems you want to pick on a different part of the language ecosystem. It's true this a matter of taste, but also worth noting that the OCaml compiler devs have made it very clear they are open to well-motivated extensions of the stdlib, and it has been growing at a decent clip in the last few years.

The size of the stdlib has a huge impact on backwards compatibility and how much pain is caused by maintaining said compatibility for the authors of the stdlib. I mean... it's hard enough for just any regular library to do that sensibly. So much so that semver (misguided as it is) was invented.

IIRC Ocaml always compiles everything from source which has its advantages, but even that is a can of worms. (And sometimes binary compatibility can actually be easier, see e.g. Scala.)

Re: We chose OCaml to write Stategraph

#127

Post by Quekid5 »

vips7L wrote: post #111
Quekid5 wrote: post #105

Earlier quoted context omitted.

Scala 3 didn't "drastically" change syntax -- most of the changes also have automatic rewrites with appropriate compiler switches. The effects story is still pretty experimental, but there's also improvements to 'effects' syntax (for-comprehensions) in "preview" for 3.7. As long as the 'effects' work will let me distinguish pure/non-pure, I'd be happy to use just that bit and stick with ZIO/TypeLevel's ecosystem... w…

Significant white space is a drastic syntax change.

Add "-noindent" to the compiler flags. Done.
Post reply on HN