Live data from Hacker News

We chose OCaml to write Stategraph

stategraph.dev

101–110 of 127 posts

Re: We chose OCaml to write Stategraph

#101
post #80

I wrote the OCamlByExample and I can only say, good luck, I don't think OCaml is ready for production, and it's generally not a very user-friendly language, but IMO it's all about having fun first and if this is what makes it fun for you guys then you should do it! Also with LLMs it's probably easier to just feed the compiler errors to an LLM and get something readable at the end.

All fine and good if you don't like it for whatever reasons, but AFAIK, people have been using OCaml software as parts of tech stacks in critical industries for around 20 years. So unless you have some qualifications to offer,

> I don't think OCaml is ready for production

seems to indicate your thinking is just not based on fact. This position is further belied by the stack of successful production applications you can see at https://ocaml.org/industrial-users/businesses.

Re: We chose OCaml to write Stategraph

#102

I like OCaml and have written the "why we chose XYZ language" posts. Most of the time the real answer is "we like it and it makes us feel good to use it". Like the answers aren't wrong per se but they're more post-facto justifications. And that's perfectly fine! 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 m…

> I think we should normalize saying that tech stack choices are subjective and preference-based.

True but I don't think this is the correct way to frame it, because it sounds unprofessional.

The correct, and understandable way is:

- the language has properties that fit the software

- the language has properties that fit the development process

- it boosts morale of development team

- the team has the required skillset

Then it's not only a preference, but a conscious engineering choice made of evaluating the different pros and cons of various alternatives.

Re: We chose OCaml to write Stategraph

#103
post #48

TIL (via a rabbit hole after reading this) that a good type system removes an absurd amount of boilerplate validation code.

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.

I’m speaking from a Python background. I love types and use them religiously, but I had no idea how much better (modulo runtime checks; that one’s obvious) others were at it.

Re: We chose OCaml to write Stategraph

#104

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

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 of things and moving off terraform apart from the stuff that doesn't change much (which will eventually get retired as well). Something like https://www.youtube.com/watch?v=q_-wnp9wRX0

Terraform variable management is our larger problem (now/nearterm) when we have to deploy numerous cells of infra that use the same project/TF files with different variables. Given the number of projects/layers of TF getting cell specific variables injected is meh.

Those variables are instance size, volume size, addresses, IAM policy, keys etc.

This is in the b2b saas world with over a million MAU. We've got islands of infra for data soverignty, some global cells where each cell can communicate back / host some shared services (internal data analytics, orchestration tooling, internal management tooling and the like).

Re: We chose OCaml to write Stategraph

#105
post #93

Earlier quoted context omitted.

Scala has some quirks but I enjoyed it relative to more popular languages and its apparent stagnation makes me sad.

Scala just seems to have an ever changing identity. Scala 3 drastically changed syntax and now they're trying to move the language from monads to effects.

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... which will probably be supported forever, regardless of whatever happens with the "effects" stuff.

Re: We chose OCaml to write Stategraph

#106
post #93

Earlier quoted context omitted.

Scala just seems to have an ever changing identity. Scala 3 drastically changed syntax and now they're trying to move the language from monads to effects.

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.

Re: We chose OCaml to write Stategraph

#107
post #39

I have worked with Haskell, Scala, and OCaml; they all bring the joy of programming into daily tasks, and OCaml has a fast compiler and a great module system. This makes it a really fun and effective language to use.

The Ocaml module system is great, but the module system in Scala isn't the usual Java package thing... it's traits. It's about as powerful as the OCaml module system on any axis I've ever used, but it's easy to miss how powerful it is. (Scala 3 added some ergonomics to make it easier to use, but it was all technically accessible in Scala 2 with 'workarounds'.)

Re: We chose OCaml to write Stategraph

#108

I like OCaml and have written the "why we chose XYZ language" posts. Most of the time the real answer is "we like it and it makes us feel good to use it". Like the answers aren't wrong per se but they're more post-facto justifications. And that's perfectly fine! 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 m…

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.

Docker?

Re: We chose OCaml to write Stategraph

#109
post #93

Earlier quoted context omitted.

Scala has some quirks but I enjoyed it relative to more popular languages and its apparent stagnation makes me sad.

Scala just seems to have an ever changing identity. Scala 3 drastically changed syntax and now they're trying to move the language from monads to effects.

Perhaps the focus of the team behind the compiler has changed over the years - but there is still backwards compatibility (via TaSTy), the new syntax changes are not mandatory (for the moment) and when they do become so there will be a fully automatic (and correct) rewrite. There are new libraries exploring "direct style" but you can still use cats-effect or ZIO if you prefer. If anything, Scala has a "too much choice" problem (and kinda a community one).

Re: We chose OCaml to write Stategraph

#110

I like OCaml and have written the "why we chose XYZ language" posts. Most of the time the real answer is "we like it and it makes us feel good to use it". Like the answers aren't wrong per se but they're more post-facto justifications. And that's perfectly fine! 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 m…

There are things that are objectively a "bad fit".

As long as you steer away from those, the "good" choices are mostly interchangeable--use what you prefer.

Post reply on HN