> 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 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..
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
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 matter to people
There are many languages that fit these requirements. I don't get the purpose of writing these posts besides a reason to go viral and get clicks talking about your product.
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.
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'.)
My concern for a team language choice is "How hard is going to be be hire people to write in this language effectively and how much will /they/ enjoy it?"
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.
Sorry for the large aside, but anyone knows the whereabouts of the Flambda2 project? Can't find the GH repo anymore, only this fork I didn't know about: https://github.com/oxcaml/oxcaml/
>One operation can't corrupt another operation's view of state because state is immutable by default.
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.
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.
18 comments
[ 0.22 ms ] story [ 37.7 ms ] threadSo 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..
EDIT: I wouldn't choose TypeScript either for this type of use case, but not for the reasons they state, that's my point
As long as you steer away from those, the "good" choices are mostly interchangeable--use what you prefer.
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.
Also with LLMs it's probably easier to just feed the compiler errors to an LLM and get something readable at the end.
just white, grey & blue.