[kbenson]

> Second don’t use databases. Databases don’t type check and aren’t compatible with your functional code written on servers.

That isn't very useful by itself. What's your suggested alternative that aligns with your advice of "don't"? How does it deal with destructive changes to data (e.g. a table drop)?

[threethirtytwo]

There are no alternatives. My point is the whole concept was designed with flaws from the beginning.

>How does it deal with destructive changes to data (e.g. a table drop)?

How does type checking deal with this? What? I'm not talking about this. I'm talking something as simple as a typo in your sql query can bring your system down without testing or a giant orm that's synced with your database.

I'm not saying distributed systems are completely solved. I'm saying a huge portion of the problems exist because of preventable flaws. Why talk about the things that can't really be easily solved and why don't we talk about the things that can be solved?

[kbenson]

Oh, I thought you were speaking more to the topic and content of the article in question, which goes to great lengths to describe the sorts of problems that are much, much harder to catch than simple compiling of queries and checking them against the database, or the message store.

Even if you were to reduce the database to a simple API, the question then remains how do you make sure to version it along with the other portions of the system that utilize it to prevent problems. The point of the article seems to be to point out that while this is a much harder problem (which I think you are categorizing as "things that can't really be easily solved"), there are actually solutions being developed in different areas that can be utilized, and it surveys many of them.

[threethirtytwo]

>Oh, I thought you were speaking more to the topic and content of the article in question, which goes to great lengths to describe the sorts of problems that are much, much harder to catch than simple compiling of queries and checking them against the database, or the message stor

Right. But we haven't even have square one solved which is the easy stuff. That's my point.

>Even if you were to reduce the database to a simple API, the question then remains how do you make sure to version it along with the other portions of the system that utilize it to prevent problems.

I said monorepo and monodeploys in this thread. But you need to actually take it further then this. Have your monorepo be written in a MONOLANGUAGE, no application language + sql, just one language to rule them all. boom. Then the static check is pervasive. That's a huge section of preventable mistakes that no longer exist, now that type that represents your table can never ever be off sync.

I know it's not "practical" but that's not my point. My point is that there's a huge portion of problems with "systems" that are literally obviously solvable and with obvious solutions it's just I'm too lazy to write a production grade database from scratch, sorry guys.

[kbenson]

> I said monorepo and monodeploys in this thread

And that helps when you are dealing with schema changes that need to be rolled out at AWS, your local DB, a Kafka cluster, how? The whole point of this article was how to approach the problem when there are different components in the system which make a monorepo and what it provides for this infeasible or impossible.

> I know it's not "practical" but that's not my point. My point is that there's a huge portion of problems with "systems" that are literally obviously solvable and with obvious solutions it's just I'm too lazy to write a production grade database from scratch, sorry guys.

The article talks about database solutions that help with this problem.

I'm uncertain how to interpret your responses in light of the article, when they seem to be ignoring most of what the article is about, which is solving exactly these problems you are talking about. Is your position that we shouldn't look for solutions to the harder problems because some people aren't even using the solutions to the easy problems?

[threethirtytwo]

The article is about coping mechanisms for a world where we already accepted fragmented systems: polyrepos, heterogeneous languages, independently versioned databases, queues, infra, and time-skewed deployments. Given that world, yes, you need sophisticated techniques to survive partial failure, temporal mismatch, and evolution over time.

That is not what I’m arguing against.

My point is more fundamental: we deliberately designed away static safety at the foundation, and then act surprised that “systems problems” exist.

Before Kafka versioning, schema migration strategies, backward compatibility patterns, or temporal reasoning even enter the picture, we already punched a hole:

Polyrepos break global static checking by construction.

Databases are untyped relative to application code

SQL is strings, not programs

Deployments are allowed to diverge by default

That entire class of failure is optional, not inherent.

When I say “we haven’t solved square one,” I’m saying: we skipped enforcing whole-system invariants, then rebranded the fallout as unavoidable distributed systems complexity.

So when you say “the article already offers solutions,” you’re misunderstanding what kind of solutions those are. They are mitigations for a world that already gave up on static guarantees, not solutions to the root design mistake.

I’m not claiming my position is practical to retrofit today. I’m claiming a huge portion of what we now call “hard systems problems” only exist because we normalized avoidable architectural holes decades ago.

You’re discussing how to live in the house after the foundation cracked.

I’m pointing out the crack was optional and we poured the concrete anyway.

I’m telling you this now so you are no longer uncertain and utterly clear about what I am saying and what my position is. If you are unclear please logically point out what isn’t clear because this phrase: “ The article talks about database solutions that help with this problem.” shows you missed the point. I am not talking about solutions that help with the problem, I am talking about solutions that make a lot of these problems non-existent within reality as we know it.

[kbenson]

You say don't use databases, and that we had the option to use something different and did not, and chose this path.

I ask you what to use instead, and how to deal with datastore versioning.

You say you're talking about how we don't have type safety that extends to the remote systems we're interacting with.

I ask how that helps versioning problems with these systems where you need to deal with applying changes across distributes systems, which specifically is not solved by having types in lockstep definition between systems, because in application of change there are problems to work thought.

You note we did all this deliberately and we didn't have to. I keep asking you what the other option is, because you keep acting like there is one, but refusing to give an example of what that would be, because a monorepo is no solution for the problems being discussed here in the article, which to be clear, are not limited to code.

You've made it very clear you think we should have done "something" else, but refuse to articulate what that is. If it's not known, or not explored, then I posit we didn't "choose" this path, it's the path that was open to us.

> You’re discussing how to live in the house after the foundation cracked.

You keep saying we should have used something else for the foundation that wouldn't crack, but refuse to explain what this mythical material is.

What is your proposed alternative, or are you just waxing theoretical?

[yencabulator]

> and time-skewed deployments.

Yeah, those pesky laws of physics, getting in the way of purity.

You simply cannot deploy simultaneously to an active fleet of servers.