4 ms·

> This is more an advertisement for a type of database than a statement that they are unnecessary. That was my reaction as well. The article's claimed argument

by pdonis 3y ago

> This is more an advertisement for a type of database than a statement that they are unnecessary. That was my reaction as well. The article's claimed argument against databases is that they are global mutable state, which is supposed to be bad. But none of what the article advocates for gets rid of global mutable state (which of course you can't do in any real world application, because the real world itself is global mutable state and anything that deals with the real world has to deal with that). It's just hawking a particular way of storing global mutable state.

adammarples 3y ago
No, they store data in 'depots', which are append only logs, like kafka. There is no mutable state.
- pdonis 3y ago
  > There is no mutable state. Yes, there is. Appending a new log entry to the depot mutates the depot. It doesn't mutate earlier records in the depot, but the depot is the entire record set, not just individual records. The record set is different after the append than before it.
a-saleh 3y ago
T.b.h. when looking at things, global mutable state might not be bad, if it is principled? I.e. I did like how Clojure had it's atomically updating refs. And you realisticaly won't get more principled than with traditional RDBS, with it's ability to transactions, rollbacks, e.t.c. Only alternative that I have seen proposed to using DBAS while not relaxing the guaranties, is to double down on event-sourcing and not having mutable-state anymore. Everything could be just a fold over all of the incomming events, right? But I don't think I have seen non-toy example of that anywhere I worked at.
- pdonis 3y ago
  > double down on event-sourcing and not having mutable-state anymore. Event sourcing doesn't get rid of mutable state. The event store gets mutated every time a new event comes in.
  - jdminhbg 3y ago
    That's not really what people mean by immutable though. What they mean is something halfway between the casual definitions of "immutable" and "persistent," in that your copy of the data at point X will always be valid, even if new data comes in later.
    - pdonis 3y ago
      > That's not really what people mean by immutable though. As far as the term "global mutable state" is concerned, which is what the article claims is bad, the event store is global mutable state. One can think of the individual event records in the store as immutable (they don't change once they're recorded), but the article is talking about the entire store, not an individual record in it. > your copy of the data at point X will always be valid If your copy of the event store is out of date (missing some events), it's not valid. A new event that your copy hasn't yet registered might change the results of queries on the store, meaning that your copy will be delivering out of date, hence invalid, query results. You can't handwave around that by gerrymandering the definition of "immutable". The simple fact is, as I said, that the real world is global mutable state, and if your app is dealing with the real world, it has to deal with that.
      - a-saleh 3y ago
        Append-only log-based data-stores are close enough in my book. And conceptually, you can then push all of those "what if I am missing events, or tey are in wrong order" into the fold over the data. Because real world is mutable data, but history of the world at any particular point isn't. It can be incomplete, it can be a personal view, I like that there are things made explicit that otherwise wouldn't. Nice abstraction. Like, if you are splitting hairs, is even array-append in Haskell immutable? It does create new data somewhere in the memory. But I don't think that makes Okasaki's thesis and book any less valuable :)

by pdonis 3y ago

adammarples 3y ago

No, they store data in 'depots', which are append only logs, like kafka. There is no mutable state.

pdonis 3y ago
> There is no mutable state. Yes, there is. Appending a new log entry to the depot mutates the depot. It doesn't mutate earlier records in the depot, but the depot is the entire record set, not just individual records. The record set is different after the append than before it.

a-saleh 3y ago

T.b.h. when looking at things, global mutable state might not be bad, if it is principled? I.e. I did like how Clojure had it's atomically updating refs. And you realisticaly won't get more principled than with traditional RDBS, with it's ability to transactions, rollbacks, e.t.c. Only alternative that I have seen proposed to using DBAS while not relaxing the guaranties, is to double down on event-sourcing and not having mutable-state anymore. Everything could be just a fold over all of the incomming events, right? But I don't think I have seen non-toy example of that anywhere I worked at.

pdonis 3y ago
> double down on event-sourcing and not having mutable-state anymore. Event sourcing doesn't get rid of mutable state. The event store gets mutated every time a new event comes in.
- jdminhbg 3y ago
  That's not really what people mean by immutable though. What they mean is something halfway between the casual definitions of "immutable" and "persistent," in that your copy of the data at point X will always be valid, even if new data comes in later.
  - pdonis 3y ago
    > That's not really what people mean by immutable though. As far as the term "global mutable state" is concerned, which is what the article claims is bad, the event store is global mutable state. One can think of the individual event records in the store as immutable (they don't change once they're recorded), but the article is talking about the entire store, not an individual record in it. > your copy of the data at point X will always be valid If your copy of the event store is out of date (missing some events), it's not valid. A new event that your copy hasn't yet registered might change the results of queries on the store, meaning that your copy will be delivering out of date, hence invalid, query results. You can't handwave around that by gerrymandering the definition of "immutable". The simple fact is, as I said, that the real world is global mutable state, and if your app is dealing with the real world, it has to deal with that.
    - a-saleh 3y ago
      Append-only log-based data-stores are close enough in my book. And conceptually, you can then push all of those "what if I am missing events, or tey are in wrong order" into the fold over the data. Because real world is mutable data, but history of the world at any particular point isn't. It can be incomplete, it can be a personal view, I like that there are things made explicit that otherwise wouldn't. Nice abstraction. Like, if you are splitting hairs, is even array-append in Haskell immutable? It does create new data somewhere in the memory. But I don't think that makes Okasaki's thesis and book any less valuable :)