Docker?

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.

I’m sorry but there is no way you can demonstrate a universal aesthetic. Your opinion of other people’s tastes does not reflect on their taste — it reflects on yours.

Imagine inheriting a project that was a joy for someone to work on instead of a slog.

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.

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.

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.

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

Here's my take. It helps you enforce properties about your data. Didn't mean to make this response so long, but alas.

  (* 
    Quick note on notation: I will use "double quotes" when referring to _values_ and `backticks` when referring to _types_.
  *)

  (* 
    Think of this as an interface. It defines the shape of a module. Notice that the interface describes a module that defines a type called `t`, and two values: "of_string", and "to_string", and they are functions with types: `string -> t`, and `t -> string`. 
  *)
  module type ID = sig
    type t
    val of_string : string -> t
    val to_string : t -> string
  end
  
  (* 
    Below this comment is a module named "Id" that _is of type_ (in other words: it _implements the interface called_) `ID`. Due to the explicit type annotation (Id : ID), now from the perspective of anywhere else in the code, the exported interface of the module "Id" is `ID`.
  
    Modules only contain two things: `type declarations`, and "values". Values are your primitives such as 1, '<', "hello", but also composite such as (fun x -> x + 1), (Some x), f x, { foo = "bar"; baz = 42 }, and even (module Id) (yes! modules can be values too!). Type declarations tell the compiler . Anything which is a value _always_ has a type that can _usually_ be inferred.
  
    No type annotation is necessary when the compiler correctly deduces the type of your value through static analysis. For instance, in the module below, "of_string" is deduced to be of type ('a -> 'a). The ' on the symbol 'a signifies a "type variable", and it means that it can be filled in with any type. For instance (t -> t) and (string -> string), but not (t -> string) or (string -> t). For those it would have to be of type ('a -> 'b). We cannot deduce this type, however, because our implementations do nothing with their inputs besides return them. Since nothing is changed, it's always the same type. 

    Now, can you spot the pink elephant? Notice how the "ID" interface from above defines "of_string" to be of type (string -> t). How can this be possible? It's because we gave the compiler a hint when we said `type t = string`. This says that a "value" of type `t` is backed by a value of type `string`. If something type checks as `t`, it also type checks as `string`. 

    So, we could reason through and say ('a -> 'a) can be instantiated to (t -> t), but `t` is also equal to `string`, so we can mentally imagine a hypothetical intermediate type... something like ({t,string} -> {t,string}). This type and type equality is visible _inside_ the module. But when the `ID` interface was applied over the `Id` module as in (Id : ID), this has the effect of hiding the type equality (the fact that `type t = string`) because in the `ID` interface we define `t` without an equals sign: `type t`. This forces us to _choose_ a concrete type to expose externally, even though the type is less general than what the implementation sees.
  
    NOTE: OCaml doesn't use parens for function definition or application. Compare this OCaml code against its Python equivalent.
  
    > let hello_world h w = (h, w)
    > let h, w = hello_world 1 2
  
    vs.
  
    > def hello_world(h, w):
    >   return (h, w)
    > h, w = hello_world(1, 2)
  *)
  module Id : ID = struct
    type t = string
    let of_string s = s
    let to_string s = s
  end
  
  let main () =
    let s = "abc123" in
    let id = Id.of_string s in
  
    (* NOTE(type error): because the built-in "print_endline" function is of type (string -> unit) and not (Id.t -> unit) *)
    (* NOTE: if an expression returns unit, you don't need to create a let binding for it. You can simply tack a semicolon to the end of it if you need sequence another expression to follow it. *)
    print_endline id;
  
    (* okay *)
    (* STDOUT: abc123 *)
    print_endline (Id.to_string id)
  ;;
  
  main ()

You could imagine implementing this pattern of defining parsers such as "of_string", "of_bytes", "of_json", "of_int", "of_db_row", "of_request", for any piece of input data. You can think of all of these functions as static constructors in OOP... you take in some data, and produce some output value: e.g. "of_string" takes in a `string` and produces a `t`.

Now, if you have a bunch of "values" of type `t`, you know that they _only_ could have been produced by the `of_string` function, because `of_string` might be the _only_ function that ends with `-> t`. Therefore, all the values maintain the same properties enforced by the `of_string` function (similar to class constructors in OOP). With this, you can create types such as `Nonnegative.t`, `Percent.t`, `Currency.t`, `Image.t`, `ProfilePicture.t`, and parsers from another type to the newly minted type.

The compiler can help you enforce these properties by providing guardrails in the form of static compiler checks (these checks are run _before_ your code can even be compiled). If I have a value of type `Nonnegative.t`, then not only do I not need to validate that it's not negative, I also don't have to validate that it's not negative everywhere else that values of that type are used -- the validation logic is baked into the constructor. Parse, don't validate.*

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

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

Best of luck. Hoping for AGPL :-)

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?

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.

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.

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.

I don’t like OCaml myself, but I’d pick it over rust here as bare metal perf is not necessary, and time wasting fighting the borrow checker is just not worth it.

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

Answer is easy, not everyone needs the performance boost provided by borrow checker, 99% of the time some kind of automatic resource management is good enough.

Rust is a pain

Rust has too many footguns. Ocaml is usually more safe.