4 ms·

I can totally see some junior dev who doesn't fully grok transactions (and not reading/understanding the "What happens when there is a race condition?" section)

I can totally see some junior dev who doesn't fully grok transactions (and not reading/understanding the "What happens when there is a race condition?" section), trying to deploy something like this and scratching their head why it falls over completely in production. The site worked fine when it was just me testing it! This is a neat proof of concept and I encourage experimentation. But, if you're developing something, please just use postgres, and don't try to cobble things together with something like this. Edit: already seeing the downvotes. Yes... classic HN... anything that goes against plain old sanity is punished.

eatonphil 3y ago
Postgres transactions are not SERIALIZABLE by default either. Though, yes, Postgres defaults will catch some more conditions than this project will. I think the important thing is to encourage devs to understand transactions in the first place.
- deleted 3y ago
  [deleted]
taywrobel 3y ago
There’s a reason that this is called “hacker news” and not “just use the industry standard for the last 3 decades news”. Won’t downvote you for giving pragmatic advice, but I appreciate projects like this that slap together disparate technologies for an interesting goal, even if it isn’t the best choice for your usual Fortune 500 company.
- latchkey 3y ago
  > I appreciate projects like this that slap together disparate technologies for an interesting goal That's exactly why I said: "This is a neat proof of concept and I encourage experimentation."
FredPret 3y ago
+1 for Postgres. It's actually ridiculous how much good software you can simply start using for free.
dilyevsky 3y ago
If you let juniors design and deploy a DB layer to prod it's your fault not the DBs. Transaction isolation is generally complicated topic that a lot of senior devs have a pretty tenuous grasp on ime and distributed Postgres solutions don't solve this particularly well either last I checked
- latchkey 3y ago
  > If you let juniors design and deploy a DB layer to prod it's your fault not the DBs. Some companies only have juniors. 28 years ago, I was the junior at my company, and the first/only engineer. Let's also be real here, most applications don't need distributed Postgres either and those that do, will have senior engineers on staff.
  - dilyevsky 3y ago
    I’m aware such places exist and my point still stands. By your own logic they dont need anything beyond webflow, squarespace or the like and shoudnt be messing with dbs (and this includes postgres)
    - latchkey 3y ago
      By your own logic, nobody becomes senior through experience.
      - dilyevsky 3y ago
        You generally become senior by getting exposure and proficiency with lots of different concepts which is the opposite to the spirit of your original comment here (hence the downvotes, I suspect). Only going with what everyone else is doing is how you become junior N times over.
        deleted 3y ago
        [deleted]
        3y ago
maxpert 3y ago
I completely agree with your analysis. Understanding the complexities of achieving convergence with basic auto-increment counters without advanced CRDT types is 101 IMO. Those familiar with these issues inherently comprehend the challenges involved. While it's plausible for someone to leverage a library atop Marmot to construct and synchronize such types, it's important to note that this tool isn't tailored for junior developers grappling with transactional intricacies. I've witnessed instances where inexperienced developers initiate transactions and make HTTP calls while holding locks, resulting in system outages. Marmot isn't intended for individuals lacking a solid understanding of distributed systems. My recommendation aligns with advising entry-level individuals to explore these tools only when they reach a scale where such complexities become pertinent.
- latchkey 3y ago
  > My recommendation aligns with advising entry-level individuals to explore these tools only when they reach a scale where such complexities become pertinent. I posit that if you're at that scale, you're figuring out how to get distributed postgres to work and not messing with things like Marmot.
  - maxpert 3y ago
    Depends on use-case. What you are building, here is one use-case for example where it made sense over postgres https://www.youtube.com/watch?v=HycGtLjlikI https://www.youtube.com/watch?v=HycGtLjlikI
    - latchkey 3y ago
      Ok, I watched that. I wasn't able to understand what the actual use-case was other than a demo of setting this up in an infinitely over complicated system.
rmbyrro 3y ago
Agree 100%. If you absolutely need to distribute data, it means you're working at a scale where things are already complex. Using SQLite for that will not simplify your life, it will just make it harder to tackle the complexity. Unless you are extremely careful, eventually consistent writes are almost guaranteed to produce behaviors that are hard / impossible to anticipate during development. And a PITA to debug.

eatonphil 3y ago

Postgres transactions are not SERIALIZABLE by default either. Though, yes, Postgres defaults will catch some more conditions than this project will. I think the important thing is to encourage devs to understand transactions in the first place.

deleted 3y ago
[deleted]

taywrobel 3y ago

There’s a reason that this is called “hacker news” and not “just use the industry standard for the last 3 decades news”. Won’t downvote you for giving pragmatic advice, but I appreciate projects like this that slap together disparate technologies for an interesting goal, even if it isn’t the best choice for your usual Fortune 500 company.

latchkey 3y ago
> I appreciate projects like this that slap together disparate technologies for an interesting goal That's exactly why I said: "This is a neat proof of concept and I encourage experimentation."

FredPret 3y ago

+1 for Postgres. It's actually ridiculous how much good software you can simply start using for free.

dilyevsky 3y ago

If you let juniors design and deploy a DB layer to prod it's your fault not the DBs. Transaction isolation is generally complicated topic that a lot of senior devs have a pretty tenuous grasp on ime and distributed Postgres solutions don't solve this particularly well either last I checked

latchkey 3y ago
> If you let juniors design and deploy a DB layer to prod it's your fault not the DBs. Some companies only have juniors. 28 years ago, I was the junior at my company, and the first/only engineer. Let's also be real here, most applications don't need distributed Postgres either and those that do, will have senior engineers on staff.
- dilyevsky 3y ago
  I’m aware such places exist and my point still stands. By your own logic they dont need anything beyond webflow, squarespace or the like and shoudnt be messing with dbs (and this includes postgres)
  - latchkey 3y ago
    By your own logic, nobody becomes senior through experience.
    - dilyevsky 3y ago
      You generally become senior by getting exposure and proficiency with lots of different concepts which is the opposite to the spirit of your original comment here (hence the downvotes, I suspect). Only going with what everyone else is doing is how you become junior N times over.
      - deleted 3y ago
        [deleted]
      - 3y ago

maxpert 3y ago

I completely agree with your analysis. Understanding the complexities of achieving convergence with basic auto-increment counters without advanced CRDT types is 101 IMO. Those familiar with these issues inherently comprehend the challenges involved. While it's plausible for someone to leverage a library atop Marmot to construct and synchronize such types, it's important to note that this tool isn't tailored for junior developers grappling with transactional intricacies. I've witnessed instances where inexperienced developers initiate transactions and make HTTP calls while holding locks, resulting in system outages. Marmot isn't intended for individuals lacking a solid understanding of distributed systems. My recommendation aligns with advising entry-level individuals to explore these tools only when they reach a scale where such complexities become pertinent.

latchkey 3y ago
> My recommendation aligns with advising entry-level individuals to explore these tools only when they reach a scale where such complexities become pertinent. I posit that if you're at that scale, you're figuring out how to get distributed postgres to work and not messing with things like Marmot.
- maxpert 3y ago
  Depends on use-case. What you are building, here is one use-case for example where it made sense over postgres https://www.youtube.com/watch?v=HycGtLjlikI https://www.youtube.com/watch?v=HycGtLjlikI
  - latchkey 3y ago
    Ok, I watched that. I wasn't able to understand what the actual use-case was other than a demo of setting this up in an infinitely over complicated system.

rmbyrro 3y ago

Agree 100%. If you absolutely need to distribute data, it means you're working at a scale where things are already complex. Using SQLite for that will not simplify your life, it will just make it harder to tackle the complexity. Unless you are extremely careful, eventually consistent writes are almost guaranteed to produce behaviors that are hard / impossible to anticipate during development. And a PITA to debug.