Hacker News Reader

Comment by latchkey | Hacker News Reader

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.

View on HN

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.

> 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."

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.

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

> 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.

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)

By your own logic, nobody becomes senior through experience.

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.

> Only going with what everyone else is doing is how you become junior N times over.

Wild thought, this is not my experience at all. I don't even understand how you can come to the conclusion.

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.

> 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.

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

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.

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

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.

Reply on news.ycombinator.com