mjarrett

What kinds of SQL queries could ClickHouse not handle? Were the limitations about expressivity of queries, performance, or something else? I'm considering using CH for storing observability (particularly tracing) data, so I'm curious about any footguns or other reasons it wouldn't be a good fit.

Isn't git-worktree designed for this kind of situation, where you could open each PR or branch in its own directory and switch your editor / other tooling between workspaces without losing state between them?

Hence, Objective Caml! This can be modeled in OCaml as an object type,

  type foo_bar = < _foo : int; _bar : string >

For a family of types matching any object with those methods, I think you can write something like

  type 'a has_foo_bar = < _foo : int; _bar : string; .. > as 'a

One of my favorite features in OCaml is labeled arguments. You get a similar flavor of partial application, but without the strict argument order requirement (most of the time -- higher order functions are strict about labeled-function arguments).

> No complex dev setup required, or RPC framework needed, it’s the same old monolith, just operated differently.

It seems to me like "operated differently" is doing a lot of heavy lifting that often involves those same frameworks or dev/testing environments. If a monolith used to communicate between workloads in-process, now there needs to be some way for those workloads to communicate between processes, and it has to continue to work in dev. The example in the article mentions roundtripping through something like Redis or Postgres, but now doesn't your dev environment need to spin up a database? What if the communication pattern isn't a shared cache, but instead a direct function call that, say, spins up a new goroutine to process some work asynchronously? Now you need to operate and maintain either an RPC protocol or an event queue, and make sure those things can be started up and discoverable during testing and local development.