10 ms·

We chose OCaml to write Stategraph

163 points by lawnchair 11mo ago

cyberpunk 11mo ago
> 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..
- ab5tract 11mo ago
  Agreed and well said!
- sausagefeet 11mo ago
  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 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.
  - deleted 11mo ago
    [deleted]
  - pjd7 11mo ago
    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 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).
    - sausagefeet 11mo ago
      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.
- leoqa 11mo ago
  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?
  - sausagefeet 11mo ago
    > 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.
    - yawaramin 11mo ago
      > 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 That's us. Especially because our teams are distributed across NA/Eastern Europe/Japan. So getting a lock is a problem because you have to wait for someone else to finish, then getting the required reviews is a problem because you have to wait for people from other timezones to come on, then by the time you're ready to re-plan after the reviews someone else has taken the lock, then you have to wait for them,...
      - cyberpunk 11mo ago
        If there was a time to insert a Jobs "you're holding it wrong" I think it would be here...
- internet_points 11mo ago
  Back in the day, before git, we had RCS. Developers would just lock files when they worked on them, and then unlock when they were done. Or you'd copy a folder manually ("branch") to work on things concurrently and then punch them in the shoulder when they forgot to unlock master so that you could lock it and check in. It worked absolutely fine, there were loads of workarounds!
koakuma-chan 11mo ago
Is any of this OCaml specific? You can check all boxes with TypeScript.
- stefanos82 11mo ago
  Does TypeScript emit machine code? OCaml gives you this option, if you need it.
  - procaryote 11mo ago
    But they say "we use ocaml [because it has types]" not "[because it can emit machine code]"
    - koakuma-chan 11mo ago
      I would go for Rust if I wanted machine code
      - deleted 11mo ago
        [deleted]
  - a-french-anon 11mo ago
    Well, TS transpiles to JS which then runs on Node, aka V8, a native JIT compiler. So yes, I guess?
    - pjmlp 11mo ago
      Kind of, given that V8 performance is never going to be as good as AOT compiled language, and JIT needs warmup time. It is no accident that famous JavaScript tools keep being rewritten into C++, Dart, Go and Rust.
- zaphar 11mo ago
  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.
laszlojamf 11mo ago
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
- jacquesm 11mo ago
  It's the combination with concurrency that makes this a hard problem. 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.
  - internet_points 11mo ago
    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?
    - phplovesong 11mo ago
      Its mostly about practicality. Haskell is kind of pain when you need IO, as in when you go there there is no way out. 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.
      - myaccountonhn 11mo ago
        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.
hardwaregeek 11mo ago
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
- criddell 11mo ago
  The first comments here are people reading this as if the authors are saying only OCaml can do this. They aren't.
  - sausagefeet 11mo ago
    Exactly! OCaml is the language I like to solve problems in, and I'm excited to solve problems in, so that's why Terrateam uses OCaml (I'm the CTO). You can do a lot (but not all) of this in Go, or TypeScript, but I don't get excited about those languages. Certainly I'll use them if I have to (our UI is written in Svelte) but building your own company is a grind, and using OCaml makes the grind just a bit more exciting, and that's an edge.
    - xedrac 11mo ago
      I've used a lot of Rust and Haskell over the past few years (I consider OCaml to be similar), and I think the benefits go beyond just user preference. But I think it's something that requires experience with "must not fail" systems failing in production, and then seeing how these languages make that failure impossible. The level of freedom and confidence that brings is amazing. And yes, that also makes them more fun to use.
    - mattgreenrocks 11mo ago
      Industry is just starting to come around to it, but I've never been more happy programming than when using a strongly-typed language with sum types. What most people fail to understand is that fighting the type checker is almost always a feature, not a bug. It is training you to write code in a way that it understands, which forces your thinking to be less sloppy, even on non-happy paths. 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.
keyle 11mo ago
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.
celpgoescheeew 11mo ago
I hope for the team to settle with a FLOSS license, so it becomes feasible to evaluate for everyone.
- lawnchair 11mo ago
  We're still figuring out what balance makes sense between openness and sustainability, and we'd rather take the time to get it right than rush into a license we'll regret later. The goal is for Stategraph to last a long time.
  - yawaramin 11mo ago
    Best of luck. Hoping for AGPL :-)
iLoveOncall 11mo ago
Everyone makes mistakes, it's good to admit them.
sgarland 11mo ago
TIL (via a rabbit hole after reading this) that a good type system removes an absurd amount of boilerplate validation code.
- yanis_t 11mo ago
  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.
  - sgarland 11mo ago
    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.
  - port11 11mo ago
    It's been 8 years and I can't imagine ever writing untyped JavaScript again. Garbage garbage garbage. If you're on TS and want end-to-end type safety, I recommend you validate everything with something like Superschema and Zapatos/PgTyped. Node with 100% type safety is wonderful to work with.
- Hasnep 11mo ago
  Do you have any good resources on this subject? I agree and would like to see what a persuasive argument for it looks like.
  - ebonnafoux 11mo ago
    The very classic parse don't valide if you haven't already read it : https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
  - deleted 11mo ago
    [deleted]
  - 11mo ago
churlin 11mo ago
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.
- therealdrag0 11mo ago
  Scala has some quirks but I enjoyed it relative to more popular languages and its apparent stagnation makes me sad.
  - vips7L 11mo ago
    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.
    - abathologist 11mo ago
      One of OCaml's outstanding, but too little mentioned, virtues is the community's commitment to extremely strong backwards compatibility guarantees.
      - Quekid5 11mo ago
        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.
        abathologist 11mo ago
        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.
markstos 11mo ago
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.
- sausagefeet 11mo ago
  It has not been a challenging finding candidates for OCaml. For the most part, people who like OCaml are chomping at the bit to find a job writing it. And for those that don't know OCaml, a lot of really good devs are excited to try something different.
a-french-anon 11mo ago
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/ https://github.com/oxcaml/oxcaml/
- debugnik 11mo ago
  That's the repo, Jane Street has rebranded their OCaml fork to OxCaml (as in oxidised, Rust-like). From the readme: > This is also the home of the Flambda 2 optimiser Their plan is to use OxCaml as their experimental fork and work with upstream to port features from it. Labelled tuples and immutable arrays for example landed in OCaml 5.4 but were originally from OxCaml.
stonemetal12 11mo ago
>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.
- jinwoo68 11mo ago
  That happens whether immutable or not. In the mutable world, you have to guard that using a mutex or something. In that case, operation 1 may be blocked by operation 2, and now you get a "stale" state from operation 2. But that's okay. You'll get a new state next time. The real problem occurs when two states are mixed and corrupted.
baby 11mo ago
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.
- abathologist 11mo ago
  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 https://ocaml.org/industrial-users/businesses.
dzonga 11mo ago
nicely designed site - welcome change from dark background, gradient colors etc. just white, grey & blue.
olcarl75 11mo ago
I wonder if the locks held in postgres are optimistic locks or what is the logic for database lock contention at the application level
pshirshov 11mo ago
All the points in the post are equally applicable to Scala too, so yes, why OCaml?
- vilunov 11mo ago
  Scala 2 is a dying language, and Scala 3 is an immature one. The ecosystem and community are also very messy, with fragmentation and witch hunts running rampant. OCaml provides same advantages, but without all the drama.
  - pshirshov 11mo ago
    > drama You don't have to participate. > immature Why? The compiler bugs are ironed out by this time. Even the most complex macros are ported. > same advantages I like the language but it lacks so many features that I can't be productive with it.

163 points by lawnchair 11mo ago

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

ab5tract 11mo ago
Agreed and well said!
sausagefeet 11mo ago
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 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.
- deleted 11mo ago
  [deleted]
- pjd7 11mo ago
  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 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).
  - sausagefeet 11mo ago
    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.
leoqa 11mo ago
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?
- sausagefeet 11mo ago
  > 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.
  - yawaramin 11mo ago
    > 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 That's us. Especially because our teams are distributed across NA/Eastern Europe/Japan. So getting a lock is a problem because you have to wait for someone else to finish, then getting the required reviews is a problem because you have to wait for people from other timezones to come on, then by the time you're ready to re-plan after the reviews someone else has taken the lock, then you have to wait for them,...
    - cyberpunk 11mo ago
      If there was a time to insert a Jobs "you're holding it wrong" I think it would be here...
internet_points 11mo ago
Back in the day, before git, we had RCS. Developers would just lock files when they worked on them, and then unlock when they were done. Or you'd copy a folder manually ("branch") to work on things concurrently and then punch them in the shoulder when they forgot to unlock master so that you could lock it and check in. It worked absolutely fine, there were loads of workarounds!

koakuma-chan 11mo ago

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

stefanos82 11mo ago
Does TypeScript emit machine code? OCaml gives you this option, if you need it.
- procaryote 11mo ago
  But they say "we use ocaml [because it has types]" not "[because it can emit machine code]"
  - koakuma-chan 11mo ago
    I would go for Rust if I wanted machine code
    - deleted 11mo ago
      [deleted]
- a-french-anon 11mo ago
  Well, TS transpiles to JS which then runs on Node, aka V8, a native JIT compiler. So yes, I guess?
  - pjmlp 11mo ago
    Kind of, given that V8 performance is never going to be as good as AOT compiled language, and JIT needs warmup time. It is no accident that famous JavaScript tools keep being rewritten into C++, Dart, Go and Rust.
zaphar 11mo ago
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.

laszlojamf 11mo ago

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

jacquesm 11mo ago
It's the combination with concurrency that makes this a hard problem. 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.
- internet_points 11mo ago
  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?
  - phplovesong 11mo ago
    Its mostly about practicality. Haskell is kind of pain when you need IO, as in when you go there there is no way out. 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.
    - myaccountonhn 11mo ago
      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.

hardwaregeek 11mo ago

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

criddell 11mo ago
The first comments here are people reading this as if the authors are saying only OCaml can do this. They aren't.
- sausagefeet 11mo ago
  Exactly! OCaml is the language I like to solve problems in, and I'm excited to solve problems in, so that's why Terrateam uses OCaml (I'm the CTO). You can do a lot (but not all) of this in Go, or TypeScript, but I don't get excited about those languages. Certainly I'll use them if I have to (our UI is written in Svelte) but building your own company is a grind, and using OCaml makes the grind just a bit more exciting, and that's an edge.
  - xedrac 11mo ago
    I've used a lot of Rust and Haskell over the past few years (I consider OCaml to be similar), and I think the benefits go beyond just user preference. But I think it's something that requires experience with "must not fail" systems failing in production, and then seeing how these languages make that failure impossible. The level of freedom and confidence that brings is amazing. And yes, that also makes them more fun to use.
  - mattgreenrocks 11mo ago
    Industry is just starting to come around to it, but I've never been more happy programming than when using a strongly-typed language with sum types. What most people fail to understand is that fighting the type checker is almost always a feature, not a bug. It is training you to write code in a way that it understands, which forces your thinking to be less sloppy, even on non-happy paths. 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.

keyle 11mo ago

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.

celpgoescheeew 11mo ago

I hope for the team to settle with a FLOSS license, so it becomes feasible to evaluate for everyone.

lawnchair 11mo ago
We're still figuring out what balance makes sense between openness and sustainability, and we'd rather take the time to get it right than rush into a license we'll regret later. The goal is for Stategraph to last a long time.
- yawaramin 11mo ago
  Best of luck. Hoping for AGPL :-)

iLoveOncall 11mo ago

Everyone makes mistakes, it's good to admit them.

sgarland 11mo ago

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

yanis_t 11mo ago
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.
- sgarland 11mo ago
  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.
- port11 11mo ago
  It's been 8 years and I can't imagine ever writing untyped JavaScript again. Garbage garbage garbage. If you're on TS and want end-to-end type safety, I recommend you validate everything with something like Superschema and Zapatos/PgTyped. Node with 100% type safety is wonderful to work with.
Hasnep 11mo ago
Do you have any good resources on this subject? I agree and would like to see what a persuasive argument for it looks like.
- ebonnafoux 11mo ago
  The very classic parse don't valide if you haven't already read it : https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
- deleted 11mo ago
  [deleted]
- 11mo ago

churlin 11mo ago

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.

therealdrag0 11mo ago
Scala has some quirks but I enjoyed it relative to more popular languages and its apparent stagnation makes me sad.
- vips7L 11mo ago
  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.
  - abathologist 11mo ago
    One of OCaml's outstanding, but too little mentioned, virtues is the community's commitment to extremely strong backwards compatibility guarantees.
    - Quekid5 11mo ago
      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.
      - abathologist 11mo ago
        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.

markstos 11mo ago

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.

sausagefeet 11mo ago
It has not been a challenging finding candidates for OCaml. For the most part, people who like OCaml are chomping at the bit to find a job writing it. And for those that don't know OCaml, a lot of really good devs are excited to try something different.

a-french-anon 11mo ago

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/ https://github.com/oxcaml/oxcaml/

debugnik 11mo ago
That's the repo, Jane Street has rebranded their OCaml fork to OxCaml (as in oxidised, Rust-like). From the readme: > This is also the home of the Flambda 2 optimiser Their plan is to use OxCaml as their experimental fork and work with upstream to port features from it. Labelled tuples and immutable arrays for example landed in OCaml 5.4 but were originally from OxCaml.

stonemetal12 11mo ago

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

jinwoo68 11mo ago
That happens whether immutable or not. In the mutable world, you have to guard that using a mutex or something. In that case, operation 1 may be blocked by operation 2, and now you get a "stale" state from operation 2. But that's okay. You'll get a new state next time. The real problem occurs when two states are mixed and corrupted.

baby 11mo ago

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.

abathologist 11mo ago
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 https://ocaml.org/industrial-users/businesses.

dzonga 11mo ago

nicely designed site - welcome change from dark background, gradient colors etc. just white, grey & blue.

olcarl75 11mo ago

I wonder if the locks held in postgres are optimistic locks or what is the logic for database lock contention at the application level

pshirshov 11mo ago

All the points in the post are equally applicable to Scala too, so yes, why OCaml?

vilunov 11mo ago
Scala 2 is a dying language, and Scala 3 is an immature one. The ecosystem and community are also very messy, with fragmentation and witch hunts running rampant. OCaml provides same advantages, but without all the drama.
- pshirshov 11mo ago
  > drama You don't have to participate. > immature Why? The compiler bugs are ironed out by this time. Even the most complex macros are ported. > same advantages I like the language but it lacks so many features that I can't be productive with it.