3 ms·

"You gotta stick the state somewhere." I like this a lot as I run into so many arguments about stateless this or stateless that, and what gets lost is that not

"You gotta stick the state somewhere." I like this a lot as I run into so many arguments about stateless this or stateless that, and what gets lost is that not contending with state is problematic. Databases are forced to get massive and do all sorts of goofy shit so some people don't have to ever think about state; this goofy shit creates interesting reliability challenges which translates to bad user experiences. For my future projects, I've decided to build my own application-as-state-database-container thing: http://www.adama-lang.org/docs/why-the-origin-story http://www.adama-lang.org/docs/why-the-origin-story Granted, I'm focused on niche board games since they redefine complexity.

coldtea 6y ago
>Databases are forced to get massive and do all sorts of goofy shit so some people don't have to ever think about state; this goofy shit creates interesting reliability challenges which translates to bad user experiences. Huh? Databases don't do anything "goofy", they implement ACID guarantees. Which absolutely beats the untold horros of Chtulu proportions that would emerge if programmers had to implement state management at the persistence layer for multiple clients themselves (they'd implement a DB + ACID poorly and in an ad-hoc way, full of holes). What people seem to forget is that relational databases are not the first technology we had for periststent state. The first versions were custom solutions per app, application-as-state and various ad-hoc such databases with their own formats and techniques, which were such a hellist landscape, devs jumped at relational databases with utter joy...
- watwut 6y ago
  > Huh? Databases don't do anything "goofy", they implement ACID guarantees. I think that he meant that functionality that should not is pushed into database. I have definitely seen project full of crazy triggers and sql procedures and so on.
- mathgladiator 6y ago
  So, databases don't do anything goofy, but developers sure do. Especially when scale (real or not) is in the picture. I'm a fan of databases myself, but I am also a fan of document stores as well.

coldtea 6y ago

>Databases are forced to get massive and do all sorts of goofy shit so some people don't have to ever think about state; this goofy shit creates interesting reliability challenges which translates to bad user experiences. Huh? Databases don't do anything "goofy", they implement ACID guarantees. Which absolutely beats the untold horros of Chtulu proportions that would emerge if programmers had to implement state management at the persistence layer for multiple clients themselves (they'd implement a DB + ACID poorly and in an ad-hoc way, full of holes). What people seem to forget is that relational databases are not the first technology we had for periststent state. The first versions were custom solutions per app, application-as-state and various ad-hoc such databases with their own formats and techniques, which were such a hellist landscape, devs jumped at relational databases with utter joy...

watwut 6y ago
> Huh? Databases don't do anything "goofy", they implement ACID guarantees. I think that he meant that functionality that should not is pushed into database. I have definitely seen project full of crazy triggers and sql procedures and so on.
mathgladiator 6y ago
So, databases don't do anything goofy, but developers sure do. Especially when scale (real or not) is in the picture. I'm a fan of databases myself, but I am also a fan of document stores as well.